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(54) Mobility management system 

(57) A wireless data network includes a wireless 
packet switched data network for end users that divides 
mobility management into local, micro, macro and glo- 
bal connection handover categories and minimizes 
handoff updates according to the handover category. 
The network integrates MAC handoff messages with 
network handoff messages. The network separately di- 
rects registration functions to a registration server and 
direct routing functions to inter-working function units. 



The network provides an intermediate XTunnel channel 
between a wireless hub (also called access hub AH) and 
an inter-working function unit (I WF unit) in a foreign net- 
work, and it provides an IXTunnel channel between an 
inter-working function unit in a foreign network and an 
inter-working function unit in a home network. The net- 
work enhances the layer two tunneling protocol (L2TP) 
to support a mobile end system, and it performs network 
layer registration before the start of a PPP communica- 
tion session. 



FIG. 2 



CM 
< 
00 

o> 

o 

5> 
o 

Q. 
LU 




Printed by Jouve. 75001 PARIS (FR) 



1 



EP 0 910 198 A2 



2 



Description 

Background of the Invention 
Field of the Invention 

[0001] The present invention relates to the manage- 
ment of mobile end systems in a packet switched data 
network that provides computer users with remote ac- 
cess to the internet and to private intranets using virtual 
private network services over a high speed, packet 
switched, wireless data link. In particular, the invention 
relates to the management of connection handovers 
when a mobile end system moves from one cell to an- 
other. 

Description Of Related Art 

[0002] FIG. 1 depicts three business entities, whose 
equipment, working together typically provide remote in- 
ternet access to user computers 2 through user mo- 
derns 4. User computers 2 and modems 4 constitute end 
systems. 

[0003] The first business entity is the telephone com- 
pany (telco) that owns and operates the dial-up plain old 
telephone system (POTS) or integrated services data 
network (ISDN) network. The telco provides the media 
in the form of public switched telephone network (PSTN) 
6 over which bits (or packets) can flow between users 
and the other two business entities. 
[0004] The second business entity is the internet serv- 
ice provider (ISP). The ISP deploys and manages one 
or more points of presence (POPs) 8 in its service area 
to which end users connect for network service. An ISP 
typically establishes a POP in each major local calling 
area in which the ISP expects to subscribe customers. 
The POP converts message traffic from the PSTN run 
by the telco into a digital form to be carried over intranet 
backbone 10 owned by the ISP or leased from an in- 
tranet backbone provider like MCI, Inc. An ISP typically 
leases fractional or full T1 lines or fractional or full T3 
lines from the telco for connectivity to the PSTN, The 
POPs and the ISP's medium data center 14 are con- 
nected together over the intranet backbone through 
router 12A. The data center houses the ISP's web serv- 
ers, mail servers, accounting and registration servers, 
enabling the ISP to provide web content, e-mail and web 
hosting services to end users. Future value added serv- 
ices may be added by deploying additional types of serv- 
ers in the data center. The ISP also maintains router 1 2 A 
to connect to public internet backbone 20. In the current 
model for remote access, end users have service rela- 
tionships with their telco and their ISP and usually get 
separate bills from both. End users access the ISP, and 
through the I SP, public internet 20, by dialing the nearest 
POP and running a communication protocol known as 
the Internet Engineering Task Force (IETF) point-to- 
point protocol (PPP). 



[0005] The third business entity is the private corpo- 
ration which owns and operates its own private intranet 
18 through router 12B for business reasons. Corporate 
employees may access corporate network 1 8 (e.g., from 
5 home or while on the road) by making POTS/ISDN calls 
to corporate remote access server 16 and running the 
IETF PPP protocol. For corporate access, end users on- 
ly pay for the cost of connecting to corporate remote ac- 
cess server 16. The ISP is not involved. The private cor- 
poration maintains router 1 2B to connect an end user to 
either corporate intranet 1 8 or public internet 20 or both. 
[0006] End users pay the telco for the cost of making 
phone calls and for the cost of a phone line into their 
home. End users also pay the ISP for accessing the 
ISP's network and services. The present invention will 
benefit wireless service providers like Sprint PCS, 
PrimeCo, etc. and benefit internet service providers like 
AOL, AT&T Worldnet, etc. 

[0007] Today, internet service providers offer internet 
access services, web content services, e-mail services, 
content hosting services and roaming to end users. Be- 
cause of low margins and no scope of doing market seg- 
mentation based on features and price, ISPs are looking 
for value added services to improve margins. In the 
short term, equipment vendors will be able to offer so- 
lutions to ISPs to enable them to offer faster access, vir- 
tual private networking (which is the ability to use public 
networks securely as private networks and to connect 
to intranets), roaming consortiums, push technologies 
and quality of service. In the longer term, voice over in- 
ternet and mobility will also be offered. ISPs will use 
these value added services to escape from the low mar- 
gin straitjacket. Many of these value added services fall 
in the category of network services and can be offered 
only through the network infrastructure equipment. Oth- 
ers fall in the category of application services which re- 
quire support from the network infrastructure, while oth- 
ers do not require any support from the network infra- 
structure. Services like faster access, virtual private net- 
working, roaming, mobility, voice, quality of service, 
quality of service based accounting all need enhanced 
network infrastructure. The invention described here will 
be either directly provide these enhanced services or 
provide hooks so that these services can be added later 
as future enhancements. Wireless service providers will 
be able to capture a larger share of the revenue stream. 
The ISP will be able to offer more services and with bet- 
ter market segmentation. 



[0008] The present invention provide end users with 
remote wireless access to the public internet, private in- 
tranets and internet service providers. Wireless access 
55 is provided through base stations in a home network and 
base stations in foreign networks with interchange 
agreements. 

[0009] It is an object of the present invention to pro- 
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vide a wireless packet switched data network for end 
users that divides mobility management into local, mi- 
cro, macro and global connection handover categories 
and minimizes handoff updates according to the hando- 
ver category. It is another object to integrate MAC hand- 
off messages with network handoff messages. It is a fur- 
ther object of the present invention to separately direct 
registration functions to a registration server and direct 
routing functions to inter-working function units. It is yet 
another object to provide an intermediate XTunnel chan- 
nel between a wireless hub (also called access hub AH) 
and an inter-working function unit (IWF unit) in a foreign 
network. It is yet another object to provide an IXTunnel 
channel between an inter-working function unit in a for- 
eign network and an inter-working function unit in a 
home network. It is yet another object to enhance the 
layer two tunneling protocol (L2TP) to support a mobile 
end system. It is yet another object to perform network 
layer registration before the start of a PPP communica- 
tion session. 

[0010] Inventive communication systems are as set 
out in the claims. The methods carried out by such sys- 
tems are as follows. 

[0011] In a network that includes a first registration 
server and first and second access points and a first ac- 
cess hub, a method of handing off a connection of a first 
mobile end system with the first access hub comprises 
steps of: initially communicating data frames between 
the first mobile end system and the first access hub 
through the first access point; sending a registration re- 
quest from the first mobile end system through the sec- 
ond access point to the first access hub to re-register 
the first mobile end system with the first access hub with- 
out informing the first registration server when the first 
mobile end system moves and re-registers through the 
second access point; linking the second access point 
with the first access hub when the first mobile end sys- 
tem re-registers through the second access point; and 
de-linking the first access point from the first access hub 
when the second access point is linked with the first ac- 
cess hub. 

[0012] Preferably the network is regarded as a foreign 
network and the foreign network further includes second 
and third access hubs and a first inter-working function; 
a home network includes a home registration server; the 
methodfurther includes a step of initially communicating 
data frames between a second mobile end system and 
the first inter-working function through the second ac- 
cess hub; the method further includes a step of sending 
a registration request from the second mobile end sys- 
tem through a third access point and through the third 
access hub to the first registration server to re-register 
the second mobile end system with the first registration 
server without informing the home registration server 
when the second mobile end system moves and re-reg- 
isters through the third access hub; the method further 
includes a step of linking the third access hub with the 
first inter-working function when the second mobile end 



system re-registers through the third access hub; and 
the method further includes a step of de-linking the sec- 
ond access h ub from the first inter-working function after 
the third access hub is linked with the first inter-working 
5 function. 

[0013] Preferably the foreign network further includes 
a fourth access hub and second and third inter-working 
functions; the home network further includes a fourth in- 
ter-working function; the method further includes a step 
of initially communicating data frames between a third 
mobile end system and the fourth inter-working function 
through the second inter-working function; the method 
further includes a step of initially communicating data 
frames between the fourth inter-working function and a 
first communications server; the method further in- 
cludes a step of sending a registration request from the 
third mobile end system through a fourth access point 
and through the fourth access hub and through the first 
registration server to the home registration server to re- 
register the third mobile end system with the home reg- 
istration server without de-linking the fourth inter-work- 
ing function from the first communications server when 
the third mobile end system moves and re-registers 
through the fourth access hub, the step of sending the 
registration request from the first registration server to 
the home registration server including a sub-step of 
sending an indication of a change from the second inter- 
working function to the third inter-working function; the 
method further includes a step of linking the third inter- 
working function with the fourth inter-working function 
when the third mobile end system re-registers through 
the fourth access hub; and the method further includes 
a step of de-linking the second inter-working function 
from the fourth inter-working function after the third in- 
ter-working function is linked with the fourth inter-work- 
ing function. 

[0014] Preferably the foreign network is regarded as 
a first foreign network and the first foreign network fur- 
ther includes a fifth inter-working function; a second for- 
eign network includes a second registration server and 
a fifth access hub and a sixth inter-working function; the 
home network further includes a seventh inter-working 
function; the method further includes a step of initially 
communicating data frames between a fourth mobile 
end system and the seventh inter-working function 
through the fifth inter-working function; the method fur- 
ther includes a step of initially communicating data 
frames between the seventh inter-working function and 
a second communications server; the method further in- 
cludes a step of sending a registration request from the 
fourth mobile end system through a fifth access pint and 
through the fifth access hub and through the second reg- 
istration server to the home registration server to re-reg- 
ister the fourth mobile end system with the home regis- 
tration server without de-linking the seventh inter-work- 
ing function from the second communications server 
when the fourth mobile end system moves and re-reg- 
isters through the fifth access hub; the method further 
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includes a step of linking the sixth inter-working function 
with the seventh inter-working function when the fourth 
mobile end system re-registers through the fifth access 
hub; and the method further includes a step of de-linking 
the fifth inter-working function from the seventh inter- 
working function after the sixth inter-working function is 
lined with the seventh inter-working function. Alterna- 
tively the foreign network is regarded as a first foreign 
network and the first foreign network further includes a 
fifth inter-working function; a second foreign network in- 
cludes a second registration server and a fifth access 
hub and a sixth inter-working function; the home net- 
work further includes seventh and eighth inter-working 
functions; the method further includes a step of initially 
communicating data frames between a fourth mobile 
end system and seventh inter-working function through 
the fifth inter-working function; the method further in- 
cludes a step of initially communicating data frames be- 
tween the seventh inter-working function and a second 
communications server; the method further includes a 
step of sending a registration request from the fourth 
mobile end system through a fifth access point and 
through the fifth access hub and through the second reg- 
istration server to the home registration server to re-reg- 
ister the fourth mobile end system with the home regis- 
tration server when the fourth mobile end system moves 
and re-registers through the fifth access hub; the meth- 
od further includes a step of linking the eighth inter-work- 
ing function with the sixth inter-working function when 
the fourth mobile end system re-registers through the 
fifth access hub; the method further includes a step of 
linking the eighth inter-working function with the second 
communications server; the method further includes a 
step of de-linking the seventh inter-working function 
from the second communications server; and the meth- 
od further includes a step of de-linking the seventh inter- 
working function from the fifth inter-working function af- 
ter the eighth inter-working function is linked with the 
sixth inter-working function. 

[0015] In a home network with a home registration 
server and a foreign network that includes a first regis- 
tration server and first and second access hubs and a 
first inter-working function, a method of handing off a 
connection of a first mobile end system with the first in- 
ter-working function comprises steps of: initially commu- 
nicating data frames between the first mobile end sys- 
tem and the first inter-working function through the first 
access hub; sending a registration request from the first 
mobile end system through a first access point and 
through the second access hub to the first registration 
server to re-register the first mobile end system with the 
first registration server without informing the home reg- 
istration server when the first mobile end system moves 
and re-registers through the second access hub; linking 
the second access hub with the first inter-working func- 
tion when the first mobile end system re-registers 
through the second access hub; and de-linking the first 
access hub from the first irrter-working function after the 



second access hub is linked with the first inter-working 
function. 

[0016] Preferably the foreign network further includes 
a third access hub and second and third inter-working 

5 functions; the home network further includes a fourth in- 
ter-working function; the method further includes a step 
of initially communicating data frames between a sec- 
ond mobile end system and the fourth inter-working 
function through the second inter-working function; the 

10 method further includes a step of initially communicating 
data frames between the fourth inter-working function 
and a first communications server; the method further 
includes a step of sending a registration request from 
the second mobile end system through a second access 

is point and through the third access hub and through the 
first registration server to the home registration server 
to re-register the second mobile end system with the 
home registration server without de-linking the fourth in- 
ter-working function from the first communications serv- 
es er when the second mobile end system moves and re- 
registers through the third access hub, the step of send- 
ing the registration request from the first registration 
server to the home registration server including a sub- 
step of sending an indication of a change from the sec- 

25 ond inter-working function to the third inter-working 
function; the method further includes a step of linking 
the third inter-working function with the fourth inter- 
working function when the second mobile end system 
re-registers through the third access hub; and the meth- 

30 od further includes a step of de-linking the second inter- 
working function from the fourth inter-working function 
after the third inter-working function is linked with the 
fourth inter-working function. 
[0017] Preferably the foreign network is regarded as 

35 a first foreign network and the first foreign network fur- 
ther includes a fifth inter-working function; a second for- 
eign network includes a second registration server and 
a fourth access hub and a sixth inter-working function; 
the home network further includes a seventh inter-work- 

40 ing function; the method further includes a step of ini- 
tially communicating data frames between athird mobile 
end system and the seventh inter-working function 
through the fifth inter-working function; the method fur- 
ther includes a step of initially communicating data 

45 frames between the seventh inter-working function and 
a second communications server; the method further in- 
cludes a step of sending a registration request from the 
third mobile end system through athird access point and 
through the fourth access hub and through the second 

50 registration server to the home registration server to re- 
register the third mobile end system with the home reg- 
istration server without de-linking the seventh inter- 
working function from the second communications serv- 
er when the third mobile end system moves and re-reg- 

55 isters through the fourth access hub; the method further 
includes a step of linking the sixth inter-working function 
with the seventh inter-working function when the third 
mobile end system re -registers through the fourth ac- 
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cess hub; and the method further includes a step of de- 
linking the fifth inter-working function from the seventh 
inter-working function after the sixth inter-working func- 
tion is linked with the seventh inter-working function. Al- 
ternatively the foreign network is regarded as a first for- 5 
eign network and the first foreign network further in- 
cludes a fifth inter-working function; a second foreign 
network includes a second registration server and a 
fourth access hub and a sixth inter-working function; the 
home network further includes seventh and eighth inter- 
working functions; the method further includes a step of 
initially communicating data frames between a third mo- 
bile end system and seventh inter-working function 
through the fifth inter-working function; the method fur- 
ther includes a step of initially communicating data 
frames between the seventh inter-working function and 
a second communications server; the method further in- 
cludes a step of sending a registration request from the 
third mobile end system through a third access point and 
through the fourth access hub and through the second 
registration server t the home registration server to re- 
register the third mobile end system with the home reg- 
istration server when the third mobile end system moves 
and re-registers through the fourth access hub; the 
method further includes a step of linking the eighth inter- 
working function with the sixth inter-working function 
when the third mobile end system re-registers through 
the fourth access hub; the method further includes a 
step of linking the eighth inter-working function with the 
second communications server; the method further in- 
cludes a step of de-linking the seventh inter-working 
function from the second communications server; and 
the method further includes a step of de-linking the sev- 
enth inter-working function from the fifth inter-working 
function after the eighth inter-working function is linked 
with the sixth inter-working function. 
[0018] In a home network with a home registration 
server and a foreign network that includes a first regis- 
tration server and a first access hub and first and second 
inter-working functions, the home network further in- 
cluding a third inter-working function, a method of hand- 
ing off a connection of a first mobile end system with a 
first communications server comprises the steps of: in- 
itially communicating data frames between the first mo- 
bile end system and the third inter-working function 
through the first inter-working function; initially, commu- 
nicating data frames between the third inter-working 
function and the first communications server; sending a 
registration request from the first mobile end system 
through a first access point and through the first access 
hub and through the first registration server to the home 
registration server to re-register the first mobile end sys- 
tem with the home registration server without de-linking 
the third inter-working function from the first communi- 
cations server when the first mobile end system moves 
and re-registers through the first access hub, the step 
of sending the registration request from the first regis- 
tration server to the home registration server including 



a sub-step of sending an indication of a change from the 
first inter-working function to the second inter-working 
function; linking the second inter-working function with 
the third inter-working function when the first mobile end 
system re-registers through the first access hub; and de- 
linking the first inter-working function from the third inter- 
working function after the second inter-working function 
is linked with the third inter-working function. 
[0019] Preferably the foreign network is regarded as 
a first foreign network and the first foreign network fur- 
ther includes fourth inter-working function; a second for- 
eign network includes a second registration server and 
a second access hub and a fifth inter-working function; 
the'home network further includes a sixth inter-working 
function; the method further includes a step of initially 
communicating data frames between a second mobile 
end system and the sixth inter-working function through 
the fourth inter-working function; the method further in- 
cludes a step of initially communicating data frames be- 
tween the sixth inter-working function and a second 
communications server; the method further includes a 
step of sending a registration request from the second 
mobile end system through a second access point and 
through the second access hub and through the second 
registration server to the home registration server to re- 
register the second mobile end system with the home 
registration server without de-linking the sixth inter- 
working function from the second communications serv- 
er when the second mobile end system moves and re- 
registers through the second access hub; the method 
further includes a step of linking the fifth inter-working 
function with the sixth inter-working function when the 
second mobile end system re-registers through the sec- 
ond access hub; and the method further includes a step 
of de-linking the fourth inter-working function from the 
sixth inter-working function after the fifth inter-working 
function is linked with the sixth inter-working function. 
Alternatively the foreign network is regarded as a first 
foreign network and the first foreign network further in- 
cludes a fourth inter-working function; a second foreign 
network includes a second registration server and a sec- 
ond access hub and a fifth inter-working function; the 
home network further includes sixth and seventh inter- 
working functions; the method further includes a step of 
initially communicating data frames between a second 
mobile end system and the sixth inter-working function 
through the fourth inter-working function; the method 
further includes a step of initially communicating data 
frames between the sixth inter-working function and a 
second communications server; the method further in- 
cludes a step of sending a registration request from the 
second mobile end system through a second access 
point and through the second access hub and through 
the second registration server to the home registration 
server to re-register the second mobile end system with 
the home registration server when the second mobile 
end system moves and re-registers through the second 
access hub; the method further includes a step of linking 
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the fifth inter-working function with the seventh inter- 
working function when the second mobile end system 
re-registers through the second access hub; the method 
further includes a step of linking the seventh inter-work- 
ing function with the second communications server; the s 
method further includes a step of de-linking the sixth in- 
ter-working function from the second communications 
server; and the method further includes a step of de- 
linking the sixth inter-working function from the fourth 
inter-working function after the seventh inter-working 10 
function is linked with the fifth inter-working function. 
[0020] I n a home network and first and second foreign 
networks, the first foreign network including a first reg- 
istration server and a first inter-working function, the 
second foreign network including a second registration 1$ 
server and a first access hub and a second inter-working 
function, the home network including a home registra- 
tion server and a third inter-working function, a method 
of handing off a connection of a first mobile end system 
with a first communications server comprises steps of: 20 
initially communicating data frames between a first mo- 
bile end system and the third inter-working function 
through the first inter-working function; initially commu- 
nicating data frames between the third inter-working 
function and the first communications server; sending a 25 
registration request from the first mobile end system 
through a first access point and through the first access 
hub and through the second registration server to the 
home registration server to re-register the first mobile 
end system with the home registration server without so 
de-linking the third inter-working function from the first 
communications server when the first mobile end sys- 
tem moves and re-registers through the first access hub; 
linking the third inter-working function with the second 
inter-working function when the first mobile end system 35 
re-registers through the first access hub; and de-linking 
the third inter-working function from the first inter-work- 
ingf unction after the third inter-working function is linked 
with the second inter-working function. 
[0021] In a home network and first and second foreign 40 
networks, the first foreign network including a first reg- 
istration server and a first inter-working function, the 
second foreign network including a second registration 
server and a first access hub and a second inter-working 
function, the home network including a home registra- 45 
tion server and third and fourth inter-working functions, 
a method of handing off a connection of a first mobile 
end system with a first communications server compris- 
es steps of: initially, communicating data frames be- 
tween a first mobile end system and the third inter-work- $0 
ing function through the first inter-working function; ini- 
tially communicating data frames between the third in- 
ter-working function and the first communications serv- 
er; sending a registration request from the first mobile 
end system through a first access point and through the ss 
first access hub and through the second registration 
server to the home registration server to re-register the 
first mobile end system with the home registration server 



when the first mobile end system moves and re-regis- 
ters through the first access hub; linking the fourth inter- 
working function with the second inter-working function 
when the first mobile end system re-registers through 
the first access hub; linking the fourth inter-working func- 
tion with the first communications server; de-linking the 
third inter-working function from the first communica- 
tions server when the fourth inter-working function is 
linked with the first communications server; and de-link- 
ing the third inter-working function from the first inter- 
working function after the fourth inter-working function 
is linked with the second inter-working function. 

Brief Description Of Drawings 

[0022] The invention will be described in detail in the 
following description of preferred embodiments with ref- 
erence to the following figures wherein: 

FIG. 1 is a configuration diagram of a known remote 
access architecture through a public switched tele- 
phone network; 

FIG. 2 is a configuration diagram of a remote access 
architecture through a wireless packet switched da- 
ta network according to the present invention; 

FIG. 3 is a configuration diagram of selected parts 
of the architecture of the network of FIG. 2 showing 
a roaming scenario; 

FIG. 4 is a configuration diagram of a base station 
with local access points; 

FIG. 5 is a configuration diagram of a base station 
with remote access points; 

FIG. 6 is a configuration diagram of a base station 
with remote access points, some of which are con- 
nected using a wireless trunk connection; 

FIG. 7 is a diagram of a protocol stack for a local 
access point; 

FIG. 8 is a diagram of a protocol stack for a remote 
access point with a wireless trunk; 

FIG. 9 is a diagram of a protocol stack for a relay 
function in the base station for supporting remote 
access points with wireless trunks; 

FIG. 10 is a diagram of protocol stacks for imple- 
menting the relay function depicted in FIG. 9; 

FIG. 11 is a diagram of protocol stacks for a relay 
function in the base station for supporting local ac- 
cess points; 
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FIG. 12 is a configuration diagram of selected parts 
of the architecture of the network of FIG. 2 showing 
a first end system registering in the home network 
from the home network and a second system reg- 
istering in the home network from a foreign network s 
using a home inter-working function for an anchor; 

FIG. 12 is a configuration diagram of selected parts 
of the architecture of the network of FIG. 2 showing 
a first end system registering in the home network 10. 
from the home network and a second system reg- 
istering in the home network from a foreign network 
using a serving inter-working function for an anchor; 

FIG. 14 is a ladder diagram of the request and. re- 1$ 
sponse messages to register in a home network 
from a foreign network and to establish, authenti- 
cate and configure a data link; 

FIG. 15 is a configuration diagram of selected parts 20 
of the architecture of the network of FIG. 2 showing 
registration requests and responses for registering 
a mobile in a home network from the home network; 

FIG. 16 is a configuration diagram of selected parts 25 
of the architecture of the network of FIG. 2 showing 
registration requests and responses for registering 
a mobile in a home network from a foreign network; 

FIG. 17 is a configuration diagram of protocol stacks 30 
showing communications between an end system 
in a home network and an inter-working function in 
the home network where the cell site has local ac- 
cess points; 

35 

FIG. 18 is a configuration diagram of protocol stacks 
showing communications between an end system 
in a home network and an inter-working function in 
the home network where the cell site has remote 
access points coupled to a wireless hub through a 40 
wireless trunk; 

FIG. 19 is a configuration diagram of protocol stacks 
showing communications between a base station 
coupled to a roaming end system and a home inter- 45 
working function; 

FIG. 20 is a configuration diagram of protocol stacks 
showing communications between an end system 
in a home network through an inter-working function so 
in the home network to an internet service provider; 

FIG. 21 is a configuration diagram of protocol stacks 
showing communications between an end system 
in a foreign network and a home registration server 55 
in a home network during the registration phase; 

FIG. 22 is a processing flow diagram showing the 



processing of accounting data through to the cus- 
tomer billing system; 

FIGS. 23 and 24 are ladder diagrams depicting the 
registration process for an end system in a home 
network and in a foreign network, respectively; 

FIGS. 25 and 26 are protocol stack diagrams de- 
picting an end system connection in a home net- 
work where a PPP protocol terminates in an inter- 
working function of the home network and where 
the PPP protocol terminates in an ISP or intranet, 
respectively; 

FIGS. 27 and 28 are protocol stack diagrams de- 
picting an end system connection in a foreign net- 
work where a PPP protocol terminates in an inter- 
working function of the foreign network and where 
the PPP protocol terminates in an ISP or intranet, 
respectively; 

FIGS. 29, 30 and 31 are ladder diagrams depicting 
a local handoff scenario, a micro handoff scenario 
and a macro handoff scenario, respectively; 

FIG. 32 is a ladder diagram depicting a global hand- 
off scenario where the foreign registration server 
changes and where home inter-working function 
does not change; 

FIG . 33 is a ladder diagram depicting a global hand- 
off scenario where both the foreign registration 
server and the home inter-working function change; 

FIGS. 34, 35 and 36 are functional flow charts de- 
picting local, micro and macro handoff procedures 
according to the present invention; 

FIG. 37 is a functional flow chart depicting global 
handoff procedures according to the present inven- 
tion when the inter-working function in the home 
network does not change; and 

FIG. 38 is a functional flow chart depicting global 
handoff procedures according to the present inven- 
tion when the inter-working function in the home 
network does change. 

Detailed Description Of Preferred Embodiments 

[0023] The present invention provides computer us- 
ers with remote access to the internet and to private in- 
tranets using virtual private network services overa high 
speed, packet switched, wireless data link. These users 
are able to access the public internet, private intranets 
and their internet service providers over a wireless link. 
The network supports roaming, that is, the ability to ac- 
cess the internet and private intranets using virtual pri- 
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vate network services from anywhere that the services 
offered by the present invention are available. The net- 
work targets users running horizontal internet and in- 
tranet applications. These applications include electron- 
ic mail, file transfer, browser based WWW access and 
other business applications built around the internet. 
Because the network will be based on the IETF stand- 
ards, it is possible to run streaming media protocols like 
RTP and conferencing protocols like H.323 over it. 
[0024] Other internet remote access technologies 
that are already deployed or are in various stages of de- 
ployment include: wire line dial-up access based on 
POTS and ISDN, XDSL access, wireless circuit 
switched access based on GSM/CDMA/TDMA, wire- 
less packet switched access based on GSM/CDMA/TD- 
MA, cable modems, and satellite based systems. How- 
ever, the present invention offers a low cost of deploy- 
ment, ease of maintenance, a broad feature set, scale- 
ability, an ability to degrade gracefully under heavy load 
conditions and support for enhanced network services 
like virtual private networking, roaming, mobility and 
quality of service to the relative benefit of users and 
service providers. 

[0025] For wireless service providers who own per- 
sonal communications system (PCS) spectrum, the 
present invention will enable them to offer wireless 
packet switched data access services that can compete 
with services provided by the traditional wire line telcos 
who own and operate the PSTN. Wireless service pro- 
viders may also decide to become internet service pro- 
viders themselves, in which case, they will own and op- 
erate the whole network and provide end to end services 
to users. 

[0026] For inter net service providers the present in- 
vention will allow them to by-pass the telcos (provided 
they purchase or lease the spectrum) and offer direct 
end to end services to users, perhaps saving access 
charges to the telcos, which may increase in the future 
as the internet grows to become even bigger than it is 
now. 

[0027] The present invention is flexible so that it can 
benefit wireless sen/ice providers who are not internet 
service providers and who just provide ISP, internet or 
private intranet access to end users. The invention can 
also benefit sen/ice providers who provide wireless ac- 
cess and internet services to end users. The invention 
can also benefit service providers who provide wireless 
access and internet services but also allow the wireless 
portion of the network to be used for access to other 
ISPs or to private intranets. 

[0028] In FIG. 2, end systems 32 (e.g., based on, for 
example, Win 95 personal computer) connect to wire- 
less network 30 using external or internal modems. 
These modems allow end systems to send and receive 
medium access control (MAC) frames over air link 34. 
External modems attach to the PC via a wired or wire- 
less link. External modems are fixed, and, for example, 
co-located with roof top mounted directional antennae. 



External modems may be connected to the user's PC 
using any one of following means: 802.3, universal se- 
rial bus, parallel port, infra-red, or even an ISM radio 
link. Internal modems are preferably PCMCIA cards for 

s laptops and are plugged into the laptop's backplane. Us- 
ing a small omni-directional antenna, they send and re- 
ceive MAC frames over the air link. 
[0029] Wide-area wireless coverage is provided by 
base stations 36. The range of coverage provided by 

10 base stations 36 depends on factors like link budget, ca- 
pacity and coverage. Base stations are typically in- 
stalled in ceil sites by PCS (personal communication 
services) wireless service providers. Base stations mul- 
tiplex end system traffic from their coverage area to the 

is system's mobile switching center (MSC) 40 over wire 
line or microwave backhaul network 38. 
[0030] The invention is independent of the MAC and 
PHY (physical) layer of the air link and the type of mo- 
dem. The architecture is also independent of the phys- 

20 ical layer and topology of backhaul network 38. The only 
requirements for the backhaul network are that it must 
be capable of routing internet protocol (IP) packets be- 
tween base stations and the MSC with adequate per- 
formance. At Mobile Switching Center 40 (MSC 40), 

25 packetdata inter-working function (IWF) 52 terminates 
the wireless protocols for this network. IP router 42 con- 
nects MSC 40 to public internet 44, private intranets 46 
or to internet service providers 46. Accounting and di- 
rectory servers 48 in MSC 40 store accounting data and 

30 directory information. Element management server 50 
manages the equipment which includes the base sta- 
tions, the IWFs and accounting/directory servers. 
[0031] The accounting server will collect accounting 
data on behalf of users and send the data to the service 

35 provider's billing system. The interface supported by the 
accounting server will send accounting information in 
American Management Association (AMA) billing 
record format over a TCP/IP (transport control protocol/ 
internet protocol) transport to the billing system (which 

40 js not shown in the figure). 

[0032] The network infrastructure provides PPP 
(point-to-point protocol) service to end systems. The 
network provides (1 ) fixed wireless access with roaming 
(log-in anywhere that the wireless coverage is available) 

45 to end systems and (2) low speed mobility and hand- 
offs. When an end system logs on to a network, in it may 
request either fixed service (i.e., stationary and not re- 
quiring handoff services) or mobile service (i.e., needing 
handoff services). An end system that does not specify 

50 fixed or mobile is regarded as specifying mobile. The 
actual registration of the end system is the result of a 
negotiation with a home registration server based on re- 
quested level of service, the level of services subscribed 
to by the user of the end system and the facilites avail- 

55 able in the network. 

[0033] If the end system negotiates a fixed service 
registration (i.e., not requiring handoff services) and the 
end system is located in the home network, an IWF (in- 
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ter-working function) is implemented in the base station 
to relay traffic between the end user and a communica- 
tions server such as a PPP server (i.e., the point with 
which to be connected, for example, an ISP PPP server 
or a corporate intranet PPP server or a PPP server op- 
erated by the wireless service provider to provide cus- 
tomers with direct access to the public internet). It is an- 
ticipated that perhaps 80% of the message traffic will be 
of this category, and thus, this architecture distributes 
IWF processing into the base stations and avoids mes- 
sage traffic congestion in a central mobile switching 
center. 

[0034] If the end system requests mobile service 
(from a home network or a foreign network) or if the end 
system request roaming service (i.e., service from the 
home network through a foreign network), two IWFs are 
established: a serving IWF typically established in the 
base station of the network to which the end system is 
attached (be it the home network or a foreign network) 
and a home IWF typically established in mobile switch- 
ing center MSC of the home network. Since this situation 
is anticipated to involve only about 20% of the message 
traffic, the message traffic congestion around the mobile 
switching center is minimized. The serving IWF and the 
wireless hub may be co-located in the same nest of com- 
puters or may even be programmed in the same com- 
puter so that a tunnel using an XTunnel protocol need 
not be established between the wireless hub and the 
serving IWF 

[0035] However, based on available facilities and the 
type and quality of service requested, a serving IWF in 
a foreign network may alternatively be chosen from fa- 
cilities in the foreign MSC. Generally, the home IWF be- 
comes an anchor point that is not changed during the 
communications session, while the serving IWF may 
change if the end system moves sufficiently. 
[0036] The base station includes an access hub and 
at least one access point (be it remote or collocated with 
the access hub). Typically, the access hub serves mul- 
tiple access points. While the end system may be at- 
tached to an access point by a wire or cable according 
to the teachings of this invention, in a preferred embod- 
iment the end system is attached to the access point by 
a wireless "air link", in which case the access hub is con- 
veniently referred to as a wireless hub. While the access 
hub is referred to as a "wireless hub" throughout the de- 
scription herein, it will be appreciated that an end system 
coupled through an access point to an access hub by 
wire or cable is an equivalent implementation and his 
contemplated by the term "access hub". 
[0037] In the invention, an end system includes an 
end user registration agent (e.g., software running on a 
computer of the end system, its modem or both) that 
communicates with an access point, and through the ac- 
cess point to a wireless hub. The wireless hub includes 
a proxy registration agent (e.g., software running on a 
processor in the wireless hub) acting as a proxy for the 
end user registration agent. Similar concepts used in, 
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for example, the IETF proposed Mobile IP standard are 
commonly referred to as a foreign agent (FA). For this 
reason, the proxy registration agent of the present in- 
vention will be referred to as a foreign agent, and as- 
£ pects of the foreign agent of the present invention that 
differ from the foreign agent of Mobile IP are as de- 
scribed throughout this description. 
[0038] Using the proxy registration agent (i.e., foreign 
agent FA) in a base station, the user registration agent 
of an end system is able to discover a point of attach- 
ment to the network and register with a registration serv- 
er in the MSC (mobile switching center) of the home net- 
work. The home registration server determines the 
availability of each of the plural inter-working function 
modules (IWFs) in the network (actually software mod- 
ules that run on processors in both the MSC and the 
wireless hubs) and assigns I WF(s) to the registered end 
system. For each registered end system, a tunnel (using 
the XTunnel protocol) is created between the wireless 
hub in the base station and an inter-working function 
(IWF) in the mobile switching center (MSC), this tunnel 
transporting PPP frames between the end system and 
the IWF. 

[0039] As used herein, the XTunnel protocol is a pro- 
tocol that provides in-sequence transport of PPP data 
frames with flow control. This protocol may run over 
standard IP networks or over point-to-point networks or 
over switched networks like ATM data networks or frame 
relay data networks. Such networks may be based on 
T1 or T3 links or based on radio links, whether land 
based or space based. The XTunnel protocol may be 
built by adapting algorithms from L2TP (level 2 transport 
protocol). In networks based on links where lost data 
packets may be encountered, a re-transmission feature 
may be a desirable option. 

[0040] The end system's PPP peer (i.e., a communi- 
cations server) may reside in the IWF or in a corporate 
intranet or ISP's network. When the PPP peer resides 
in the IWF, an end system is provided with direct internet 
access. When the PPP peer resides in an intranet or 
ISP, an end system is provided with intranet access or 
access to an ISP. In order to support intranet or ISP ac- 
cess, the IWF uses the layer two tunneling protocol 
(L2TP) to connect to the intranet or ISPs PPP server. 
From the point of view of the intranet or ISP's PPP serv- 
er, the IWF looks like a network access server (NAS). 
PPP traffic between the end system and the IWF is re- 
layed by the foreign agent in the base station. 
[0041] In the reverse (up link) direction, PPP frames 
traveling from the end system to the IWF are sent over 
the MAC and air link to the base station. The base sta- 
tion relays these frames to the IWF in the MSC using 
the XTunnel protocol. The IWF delivers them to a PPP 
server for processing. For internet access, the PPP 
server may be in the same machine as the IWF, For ISP 
or intranet access, the PPP server is in a private network 
and the IWF uses the layer two tunneling protocol 
(L2TP) to connect to it. 
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[0042] In the forward (down link) direction, PPP 
frames from the PPP server are relayed by the I WF to 
the base station using the XTunnel protocol. The base 
station de-tunnels down link frames and relays them 
over the air link to the end system, where they are proc- s 
essed by the end system's PPP layer. 
[0043] To support mobility, support for hand-offs are 
included. The MAC layer assists the mobility manage- 
ment software in the base station and the end system 
to perform hand-offs efficiently. Hand-off§ are handled 
transparently from the peer PPP entities and the L2TP 
tunnel. If an end system moves from one base station 
to another, a new XTunnel is created between the new 
base station and the original I WF. The old XTunnelUom 
the old base station will be deleted. PPP frames .will 
transparently traverse the new path, 
[0044] The network supports roaming (i.e., when the 
end user connects to its home wireless service provider 
through a foreign wireless service provider). Using this 
feature, end systems are able to roam away from the 
home network to a foreign network and still get service, 
provided of course that the foreign wireless service pro- 
vider and the end system's home wireless service pro- 
vider have a service agreement. 
[0045] In FIG. 3, roaming end system 60 has traveled 
to a location at which foreign wireless service provider 
62 provides coverage. However, roaming end system 
60 has a subscriber relationship with home wireless 
service provider 70. In the present invention, home wire- 
less service provider 70 has a contractual relationship 
with foreign wireless service provider 62 to provide ac- 
cess services. Therefore, roaming end system 60 con- 
nects to base station 64 of foreign wireless service pro- 
vider 62 over the air link. Then, data is relayed from 
roaming end system 60 through base station 64, 
through serving IWF 66 of foreign wireless service pro- 
vider 62, to home IWF 72 of home wireless service pro- 
vider 70, or possibly through home IWF 72 of home wire- 
less service provider 70 to internet service provider 74. 
[0046] An inter-service provider interface, called the 
l-interface, is used for communications across wireless 
service provider (WSP) boundaries to support roaming. 
This interface is used for authenticating, registering and 
for transporting the end system's PPP frames between 
the foreign WSP and the home WSP. 
[0047] PPP frames in the up link and the down link 
directions travel through the end system's home wire- 
less service provider (WSP). Alternatively, PPP frames 
directly transit from the foreign WSP to the destination 
network. The base station in the foreign WSP is the end 
system's point of attachment in the foreign network. This 
base station sends (and receives) PPP frames to (and 
from) a serving IWF in the foreign WSP's mobile switch- 
ing center. The serving IWF connects over the l-inter- 
face to the home IWF using a layer two tunnel to trans- 
port the end system's PPP frames in both directions. 
The serving IWF in the foreign WSP collects accounting 
data for auditing. The home IWF in the home WSP col- 



lects accounting data for billing. 
[0048] During the registration phase, a registration 
server in the foreign WSP determines the identity of the 
roaming end system's home network. Using this infor- 
mation, the foreign registration server communicates 
with the home registration server to authenticate and 
register the end system. These registration messages 
flow overthe l-interface. Once the end system has been 
authenticated and registered, a layer two tunnel is cre- 
ated between the base station and the serving IWF us- 
ing the XTUNNEL protocol and another layer two tunnel 
is created between the serving IWF and the home IWF 
over the l-interface. The home IWF connects to the end 
system's PPP peer as before, using L2TP (level 2 tunnel 
protocol). During hand-offs, the location of the home 
IWF and the L2TP tunnel remains fixed. As the end sys- 
tem moves from one base station to another base sta- 
tion, a new tunnel is created between the new base sta- 
tion and the serving IWF and the old tunnel between the 
old base station and the serving IWF is deleted. If the 
end system moves far enough, so that a new serving 
IWF is needed, a new tunnel will be created between 
the new serving IWF and the home IWF The old tunnel 
between the old serving and the home will be deleted. 
[0049] To support roaming, the l-interface supports 
authentication, registration and data transport services 
across wireless service provider boundaries. Authenti- 
cation and registration services are supported using the 
IETF Radius protocol. Data transport services to trans- 
fer PPP frames over a layer two tunnel are supported 
using the l-XTunnel protocol. This protocol is based on 
the IETF L2TP protocol. 

[0050] As used in this description, the term home IWF 
refers to the IWF in the end system=s home network. 
The term serving IWF refers to the IWF in the foreign 
network which is temporarily providing service to the 
end system. Similarly, the term home registration server 
refers to the registration server in the end system's 
home network and the term foreign registration server 
refers to the registration server in the foreign network 
through which the end system registers while it is roam- 
ing. 

[0051] The network supports both fixed and dynamic 
IP address assignment for end systems. There are three 
types of IP addresses that need to be considered. Two 
are associated with mobile IP and the third is associated 
with PPP. The mobile IP RFC mandates that an end sys- 
tem using mobile IP have a fixed home address. Mobile 
IP also mandates that a care-of -address be used as the 
end point of the mobile IP tunnel (Xtunnel in our case). 
For the present network, the care-of-address used for 
mobile IP tunneling (i.e. the XTunnet) is the IP address 
of the base station. The use of the fixed home address 
is deprecated for the network. In mobile IP registration 
request packets, the value of the home address field is 
set to 0.0.0.0. A structured User-Name field in the sim- 
plified mail transfer protocol (SMTP) format is added to 
the mobile IP registration request packet. This is of the 
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form user@domain. The domain sub-field is used to 
identify the user's home domain and is a fully qualified 
domain name. The user sub-field is used to identify the 
user in the home domain. The User-Name is stored on 
the end system and in the subscriber data-base at the 
MSG and is assigned to the user when he or she sub- 
scribes to the service. The domain sub-field of the User- 
Name is used during roaming to identify roaming rela- 
tionships and the home registration server for purposes 
of registration and authentication. 
[0052] The PPP IPCP is used to negotiate the IP ad- 
dress for the end system. Using IP configuration proto- 
col IPCP, the end system is able to negotiate a fixed or 
dynamic IP address. 

[0053] Although the use of the structured user-name 
field and the non-use of the home address is a feature 
that characterizes the present invention over a known 
mobile IP, the network may be enhanced to also support 
end systems that have no user-name and only a non- 
null home address, if mobile IP and its use in conjunction 
with PPP end systems becomes popular. The PPP serv- 
er may be configured by the service provider to assign 
IP addresses during the IPCP address assignment 
phase that are the same as the end system's home ad- 
dress. In this case, the home address and the IPCP as- 
signed IP address will be identical. 
[0054] In FIG. 4, base station 64 and air links from end 
systems form wireless sub-network 80 that includes the 
air links for end user access, at least one base station 
(e.g., station 64) and at least one backhaul network (e. 
g., 38 of FIG. 2) from the base station to MSC 40 (FIG. 
2). The wireless sub-network architecture of, for exam- 
ple, a 3-sectored base station includes the following log- 
ical functions. 

1 . Access point function. Access points 82 perform 
MAC layer bridging and MAC layer association and 
dissociation procedures. An access point includes 
a processor (preferably in the form of custom appli- 
cation specific integrated circuit ASIC), a link to a 
wireless hub (preferably in the form of an Ethernet 
link on a card or built into the ASIC), a link to an 
antenna (preferably in the form of a card with a data 
modulator/demodulator and a transmitter/receiver), 
and the antenna to which the end system is cou- 
pled. The processor runs software to perform a data 
bridging function and various other functions in sup- 
port of registration and mobility handovers as fur- 
ther described herein. See discussion with respect 
to FIGS. 7, 8 and 11. 

Access points (APs) take MAC layer frames 
from the air link and relay them to a wireless hub 
and vice versa. The MAC layer association and dis- 
association procedures are used by APs to main- 
tain a list of end system MAC addresses in their 
MAC address filter table. An AP will only perform 
MAC layer bridging on behalf of end systems whose 
MAC addresses are present in the table. An access 



point and its associated wireless hub are typically 
co-located. In its simpliest form, an access point is 
just a port into a wireless hub. When the APs and 
the wireless hub are co-located in the same cell site, 
5 they may be connected together via a IEEE 802.3 
link. Sometimes, access points are located remote- 
ly from the wireless hub and connected-via a long 
distance link like a wired T1 trunk or even a wireless 
trunk. For multi-sector cells, multiple access points 
10 (i.e., one per sector) are used. 

2. Wireless hub function. Wireless hub 84 performs 
the foreign agent (FA) procedures, backhaul load 
balancing (e.g., over multiple TVs), backhaul net- 

is work interfacing, and the xf unne/procedures. When 
support for quality of service (QOS) is present, the 
wireless hub implements the support for QOS by 
running the xtunnel protocol over backhauls with 
different QOS attributes. In a multi-sector cell site, 

20 a single wireless hub function is typically shared by 
multiple access points. 

A wireless hub includes a processor, a link to 
one or more access points (preferably in the form 
of an Ethernet link on a card or built into an ASIC), 

25 and a link to a backhaul line. The backhaul line is 
typically a T1 or T3 communications line that termi- 
nates in the mobile switching center of the wireless 
service provider. The link to the backhaul line for- 
mats data into a preferred format, for example, an 

30 Ethernet format, a frame relay format or an ATM for- 
mat. The wireless hub processor runs software to 
support data bridging and various other functions 
as described herein. See discussion with respect to 
FIGS. 9, 10 and 11. 

35 

[0055] The base station design supports the following 
types of cell architectures. 

1. Local AP architecture. In a local AP architecture, 
40 access points have a large (> = 2km, typically) 

range. They are co-located in the cell site with the 
wireless hub (FIG. 4). Access points may be con- 
n ected to th e wi re less h ub us ing an I E E E 802 . 3 net- 
work or may be directly plugged into the wireless 
45 hub's backplane or connected to the wireless hub 
using some other mechanism (e.g. universal serial 
bus, printer port, infra-red, etc.). It will be assumed 
that the first alternative is used for the rest of this 
discussion. The cell site may be omni or sectored 
so by adding multiple access points and sectored an- 
tennas to a wireless hub. 

2. Remote AP architecture. In a remote AP archi- 
tecture, access points usually have a very small 

55 range, typically around 1 km radius. They are locat- 
ed remotely (either indoors or outdoors) from the 
wireless hub. A T1 or a wireless trunk preferably 
links remote access points to the cell site where the 
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wireless hub is located. From the cell site, a wire 
line backhaul or a microwave link is typically used 
to connect to the IWF in the MSC. It wireless trunk- 
ing between the remote AP and the wireless hub is 
used, omni or sectored wireless radios for trunking s 
are utilized. The devices for trunking to remote ac- 
cess points are preferably co-located with the wire- 
less hub and may be connected to it using an IEEE 
802.3 network or may be directly plugged into the 
wireless hub=s backplane. These devices will be re- 10 
f erred to by the term trunk AR 

3. Mixed AP architecture. In a mixed architecture, 
the wireless sub-network will have to support re- 
mote and local access points. Remote access is 
points may be added for hole filling and other ca- 
pacity reasons. As described earlier, T1 or wireless 
trunks may be used to connect the remote AP to the 
wireless hub. 

20 

[0056] FIG. 5 shows a cell with three sectors using 
local APs only. The access points and the wireless hub 
are co-located in the base station and are connected to 
each other with 802.3 links. 

[0057] FIG. 6 shows an architecture with remote ac- 25 
cess points 82 connected to wireless hub 84 using wire- 
less trunks 86. Each trunk access point in the base sta- 
tion provides a point to multi-point wireless radio link to 
the remote micro access points (R-AP in figure). The 
remote access points provide air link service to end sys- 30 
terns. The wireless hub and the trunk access points are 
co- located in the base station and connected together 
via 802.3 links. This figure also shows remote access 
points 82R connected to the wireless hub via point to 
point T1 links. In this scenario, no trunk APs are re- 35 
quired. 

[0058] To support all of the above cell architectures 
and the different types of access points that each cell 
might use, the network architecture follows the following 
rules: 40 

1 . Access points function as MAC layer bridges. Re- 
mote access points perform MAC bridging between 
the air link to the end systems and the wireless or 

T1 trunk to the cell site. Local access points perform 45 
MAC bridging between the air link to the end sys- 
tems and the wireless hub. 

2. Trunk access points also function as MAC layer 
bridges. They perform MAC bridging between the so 
trunk (which goes to the access points) and the 
wireless hub. 

3. The wireless hub is connected to all co-located 
MAC bridges (i.e. local access points or trunk ac- 55 
cess points) using a 802.3 link initially. 

[0059] Additionally, where local access points or re- 



mote access points with T1 trunks are used, the follow- 
ing rules are followed. 

1 . Local access points are co-located with the wire- 
less hub and connected to it using point to point 
802.3 links or a shared 802.3 network. The first ap- 
proach is used if the access points can not perform 
intelligent MAC layer bridging functions or if intelli- 
gent MAC layer bridging is deemed too inefficient. 
Remote access points are connected to the wire- 
less hub using point to point T1 trunks. 

2. Sectorization is supported by adding access 
' points with sectored antennas to the cell site. 

3. End system registration is done using mobile IP 
techniques. For each access point connected to the 
wireless hub, there is a foreign agent executing in 
the wireless hub. MAC layer association proce- 
dures are used to keep the MAC address filter ta- 
bles of the access points up to date and to perform 
MAC layer bridging efficiently. The wireless hub par- 
ticipates in MAC association functions so that only 
valid MAC addresses are added to the MAC ad- 
dress filter tables of the access points. 

4. The foreign agent in the wireless hub relays 
frames from the access points to the MSC IWF and 
vice versa using the xtunnel protocol. The MAC ad- 
dress filter table is used to filter out those unicast 
MAC data frames whose MAC addresses are not 
present in the table. The APs always forward MAC 
broadcast frames and MAC frames associated with 
end system registration functions regardless of the 
contents of the MAC address filter table. 

5. Local access points use ARP to resolve MAC ad- 
dresses for routing IP traffic to the wireless hub. 
Conversely, the wireless hub also uses ARP to 
route IP packets to access points. UDP/IP is used 
for network management of access points. 

6. Remote access points connected via T1 do not 
use ARP since the link will be a point to point link. 

7. Support for hand-offs uses mobile IP procedures 
with assistance from the MAC layer. 

[0060] In a cell architecture using wireless trunks and 
trunk APs, the following rules are followed. 

1 . Trunk access points are co-located with the wire- 
less hub and connected to it using point to point 
802.3 links. This is done to make it easier to route 
MAC frames. Note that a shared 802.3 network 
could also be used, provided the trunk access 
points can intelligently perform their MAC bridging 
functions. 
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2. Wireless trunk sectorization is supported by add- 
ing trunk access points with sectored antennas to 
the cell site. 

3. Hand-off s across backhaul sectors are done us- s 
ing mobile IP techniques. For each backhaul sector, 
there is a foreign agent executing in the wireless 
hub. 

4. The trunk APs do not need to participate in MAC 10 
layer end system association and hand off proce- 
dures. Their MAC address filter tables will be dy- 
namically programmed by the wireless hub as end 
systems register with the network. The MAC ad- 
dress filter table is used to filter out unicast MAC 15 
frames. Broadcast MAC frames or MAC frames 
containing registration packets are allowed to al- 
ways pass through. 

5. Trunk APs use ARP to resolve MAC addresses 20 
for routing IP traffic to the wireless hub. Conversely, 

the wireless hub use ARP to route IP packets to 
trunk APs. UDP/I P is used for network management 
of trunk APs. 

25 

6. In a single wireless trunksector, MAC association 
and hand-offs from one access point to another is 
done using the MAC layer. Using these MAC layer 
procedures, end systems associate with access 
points. As end systems move from one access point 30 
to another access point, the access points will use 

a MAC hand off protocol to update their MAC ad- 
dress filter tables. The wireless hub at the cell site 
provides assistance to access points to perform this 
function. This assistance includes relaying MAC 35 
layer hand off messages (since access points will 
not be able to communicate directly over the MAC 
layer with each other) and authenticating the end 
system for MAC layer registration and hand off and 
for updating the MAC address filter tables of the ac- *o 
cess points. 

7. The foreign agent for a wireless trunk sector is 
responsible for relaying frames from its trunk AP to 
the MSC and vice versa using the xtunnel protocol. 4$ 
Thus, the foreign agent for a trunk AP does not care 
about the location of the end system with respect to 
access points within that wireless trunk sector. In 

the down link direction, it just forwards frames from 
the mobile IP tunnel to the appropriate trunk AP so 
which uses MAC layer bridging to send the frames 
to all the remote access points attached in that 
backhaul sector. The access points consult their 
MAC address filter tables and either forward the 
MAC frames over the access network or drop the 55 
MAC frames. As described above, the MAC ad- 
dress filter tables are kept up to date using MAC 
layer association and hand off procedures. In the 



up link direction, MAC frames are forwarded by the 
access points to the backhaul bridge which for- 
wards them to the foreign agent in the wireless hub 
using the 802.3 link. 

8. ARP is not be used for sending or receiving IP 
packets to the remote access points. The access 
points determines the MAC address of the wireless 
hub using BOOTP procedures. Conversely, the 
wireless hub is configured with the MAC address of 
remote access points. UDP/I P is used for network 
management of access points and for end system 
association and hand off messages. 

[0061] IEEE 802.3 links in the cell site may be re- 
placed by higher speed links. 
[0062] FIG. 7 shows the protocol stack for a local ac- 
cess point. At the base of the stack is physical layer PHY 
Physical layer PHY carries data to and from an end sys- 
tem as it is transmitted and received in a stream to and 
from the data modulator and demodulator, respectively. 
When received from an end system, the AP receives 
data from the physical layer and unpacks it into MAC 
frames (the MAC layer). The MAC frames are then 
repacked into an Ethernet physical layer fomat (IEEE 
802.3 format) where it is send via the Ethernet link to 
the wireless hub. When the AP's processor receives da- 
ta from the wireless hub via its Ethernet link (i.e., the 
physical layer), the data to be transmitted to an end sys- 
tem, the AP packs the data in a medium access control 
(MAC) format, and sends the MAC layer data to its mod- 
ulator to be transmitted to the end system. 
[0063] In FIG. 8, the MAC and PHY layers to/from the 
end system of FIG. 7 are replaced by a MAC and PHY 
for the trunk to the cell site for a remote access point. 
Specifically, foraTI trunk, the high level data link control 
protocol (HDLC protocol) is preferably used over the T1 . 
[0064] FIG. 9 depicts the protocol stack for the wire- 
less hub that bridges the backhaul line and the trunk to 
the remote access point. The trunk to the remote APs 
are only required to support remote access points (as 
distinct from Ethernet coupled access points). The MAC 
and PHY layers for the wireless trunk to the remote APs 
provide a point to multipoint link so that one trunk may 
be used to communicate with many remote APs in the 
same sector. 

[0065] The wireless hub bridges the trunk to the re- 
mote APs and the backhaul line (e.g., T1 or T3) to the 
network's mobile switching center (MSC). The protocol 
stack in the wireless hub implements MAC and PHY lay- 
ers to the MSC on top of which is implemented an IP 
layer (Internet Protocol) on top of which is implemented 
a UDP layer (Universal Datagram Protocal, in combina- 
tion refered to as UDP/I P) for network management on 
top of which is implemented an XTunnel protocol. The 
XTunnel protocol is a new format that includes aspects 
of the proposed IETF Mobile IP standard and aspects 
of the Level 2 Tunnel Protocol (L2TP). The XTunnel pro- 
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tocol is used to communicate from the wireless hub to 
the MSC and between inter-working functions (IWFs) in 
different networks or the same network. 
[0066] In FIG. 10, the protocol stack for the relay func- 
tion in the base station for supporting remote access 
points is shown. The relay function includes an interface 
to the backhaul line (depicted as the wireless hub) and 
ah interface to the remote AP (depicted as a trunk AP). 
From the point of view of the wireless hub, the trunk AP 
(depicted in FIGS. 7 and 10) actually behaves like the 
AP depicted in FIG, 7. Preferably, the base station pro- 
tocol stacks are split up into a wireless hub and a trunk 
AP with an Ethernet in between. In an N-sector wireless 
trunk, there are N wireless trunk APs in the cell site and 
one wireless hub. 

[0067] In FIG. 11, the base station protocol stack for 
a cell architecture using a local AP is shown. The relay 
function includes an interface to the backhaul line (de- 
picted as the wireless hub) and an air link interface to 
the end system (depicted as an AP). From the point of 
view of the wireless hub, the AP (depicted in FIGS. 8 
and 11) actually behaves like the trunk AP depicted in 
FIG. 8. Preferably, the base station protocol stacks are 
split up into a wireless hub and a trunk AP with an Ether- 
net in between. In a N-sector cell, there are N access 
points and a single wireless hub. 
[0068] The backhaul network from the base station to 
the MSC has the following attributes. 

1 . The network is capable of routing IP datagrams 
between the base station and the MSC. 

2. The network is secure. It is not a public internet. 
Traffic from trusted nodes only are allowed onto the 
network since the network will be used for not only 
transporting end system traffic, but also for trans- 
porting authentication, accounting, registration and 
management traffic. 

3. The network has the necessary performance 
characteristics. 

[0069] In typical application, the service provider is re- 
sponsible for installing and maintaining the backhaul 
network on which the equipment is installed. 
[0070] The base stations supports the following back- 
haul interfaces for communicating with the MSC. 

1. Base stations support IP over PPP with HDLC 
links using point to point T1 or fractional T3 links. 

2. Base stations support IP over frame relay using 
T1 or fractional T3 links. 

3. Base stations support IP over AAL5/ATM using 
T1 or fractional T3 links. 

[0071] Since all of the above interfaces are based on 



IETF standard encapsulations, commercial routers may 
be used in the MSC to terminate the physical links of the 
backhaul network. Higher layers are passed on and 
processed by the various servers and other processors. 

5 [0072] End system registration procedures above the 
MAC layer are supported. In the following, end system 
registration procedures at the MAC layer are ignored ex- 
cept where they impact the layers above. 
[0073] End systems may register for service on their 

10 home network or from a foreign network. In both sce- 
narios, the end system uses a foreign agent (FA) in the 
base station to discover a point of attachment to the net- 
work and to register. In the former case, the FA is in the 
end system's home network. In the latter case, the FA 

is is in a foreign network. In either case, the network uses 
an IWF in the end system's home network as an anchor 
point (i.e., unchanging throughout the session in spite 
of mobility). PPP frames to and from the end system 
travel via the FA in the base station to the IWF in the 

20 home network. If the end system is at home, the home 
IWF is directly connected by means of the xtunnel pro- 
tocol to the base station. If the end system is roaming, 
a serving IWF in the foreign network is connected to the 
home IWF over an (-interface. The serving IWF relays 

25 frames between the base station and the home IWF. 
From the home IWF, data is sent to a PPP server which 
may reside in the same IWF or to a separate server us- 
ing the L2TP protocol. The separate server may be 
owned and operated by a private network operator (e. 

30 g. ISP or corporate intranet) who is different from the 
wireless service provider. For the duration of the ses- 
sion, the location of the home IWF and the PPP server 
remains fixed. If the end system moves while connect- 
ed, it will have to re-register with a new foreign agent. 

35 However, the same home IWF and PPP server contin- 
ues to be used. A new xtunnel is created between the 
new FA and the IWF and the old xtunnel between the 
old foreign agent and the IWF is destroyed. 
[0074] FIG. 12 shows this network configuration for 

40 two end systems A and B, both of whose home wireless 
network is wireless service provider A (WSP-A). One 
end system is registered from the home wireless net- 
work and the other from a foreign wireless network. The 
home IWF in WSP-A serves as the anchor point for both 

45 end systems. For both end systems, data is relayed to 
the home IWF. The home IWF connects to an internet 
service provider's PPP server owned by ISP-A. Here it 
is assumed that both end systems have subscribed to 
the same ISP. If that were not the case, then the home 

50 IWF would be shown also connected to another ISP 
[0075] Within a wireless service providers network, 
data between base stations and the IWF is carried using 
the xtunnel protocol. Data between the IWF and the PPP 
server is carried using Level 2 Tunneling Protocol 

55 (L2TP). Data between the serving IWF and the home 
IWF is carried using the l-xtunnel protocol. 
[0076] Always using an IWF in the home network has 
its advantages and disadvantages. An obvious advan- 
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tage is simplicity. A disadvantage is that of always hav- 
ing to relay data to and from a possibly remote home 
IWF The alternative is to send all the necessary infor- 
mation to the serving IWF so that it may connect to the 
end system's ISP/intranet and for the serving IWF to 
send accounting information in near real time back to 
the accounting server in the home network. This func- 
tionality is more complex to implement, but more effi- 
cient because it reduces the need to relay data over po- 
tentially long distances from the foreign network to the 
home network. 

[0077] For example, consider a case of a user who 
roams from Chicago to Hong Kong. If the user's home 
network is in Chicago and the user registers using a 
wireless service provider in Hong Kong, then in the fjrst 
configuration, the anchor point will be the home IWF in 
Chicago and all data will have to be relayed from Hong 
Kong to Chicago and vice versa. The home IWF in Chi- 
cago will connect to the user's ISP in Chicago. With the 
second configuration, the end system user will be as- 
signed an ISP in Hong Kong. Thus, data will not always 
have to be relayed back and forth between Chicago and 
Hong Kong. In the second configuration, the serving 
IWF will serve as the anchor and never change for the 
duration of the session even if the end system moves. 
However, the location of the FA may change as a result 
of end system movement in Hong Kong. 
[0078] FIG. 13 shows the second network configura- 
tion. In this figure, the home network for end system A 
and B is WSP-A. End system A registers from its home 
network, using its home IWF as an anchor point, and 
also connects to its ISP-A using the ISPs PPP server. 
End system B registers from the foreign network of 
WSP-B and uses a serving IWF which serves as the an- 
chor point and connects the end system to an ISP using 
the ISP's PPP server. In this configuration, data for end 
system B does not have to be relayed from the foreign 
network to the home network and vice versa. 
[0079] In order for this configuration to work, not only 
must there be roaming agreements between the home 
and the foreign wireless service providers, but there also 
must be agreements between the foreign wireless serv- 
ice provider and the end system's internet service pro- 
vider directly or through an intermediary. Inthe example 
above, not only must the wireless service provider in 
Hong Kong have a business agreement with the wire- 
less service provider in Chicago, but the WSP in Hong 
Kong must have a business agreement with the user's 
Chicago I SP and access to the Chicago ISPs PPP serv- 
er in Hong Kong or a business agreement with another 
ISP locally in Hong Kong who has a business agreement 
for roaming with the user's Chicago ISP Additionally, the 
WSP in Hong Kong must be able to discover these 
roaming relationships dynamically in order to do user 
authentication and accounting and to set up the appro- 
priate tunnels. 

[0080] It is difficult for those companies who are in the 
Internet infrastructure business to work out suitable 
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standards in the IETF for all of these scenarios. Thus, 
a preferable embodiment for the present invention is to 
implement the simpler, potentially less efficient configu- 
ration, where the IWF in the home network is always 
5 used as the anchor point. However, in the presence of 
suitable industry standardization of protocols for Inter- 
net roaming, the second configuration should be regard- 
ed as equivalent or alternative embodiment. 
[0081] An end system will have to register with the 
wireless network before it can start PPP and send and 
receive data. The end system first goes through the FA 
discovery and registration phases. These phases au- 
thenticate and register the end system to the wireless 
service provider. Once these phases are over, the end 
system starts PPP This includes the PPP link establish- 
ment phase, the PPP authentication phase and the PPP 
network control protocol phase. Once these phases are 
over, the end system is able tosend and receive IP pack- 
ets using PPP. 

[0082] The following discussion assumes that the end 
system is roaming and registering from a foreign net- 
work. During the FA discovery phase, the end system 
(through its user registration agent) solicits an advertise- 
ment from the foreign agent. The user registration agent 
uses advertisement messages sent by a near by foreign 
agent to discover the identity of the FA and to register. 
During this phase, the user registration agent of the end 
system selects the FA's care-of-address and issues a 
registration request to it. The FA acting as a proxy reg- 
istration agent forwards the registration request to its 
registration server (the registration server in the foreign 
WSP). The registration server uses User-Name from the 
user registration agent's request to determine the end 
system's home network, and forwards the registration 
request for authentication to a registration server in the 
home network. Upon receiving the registration request 
relayed by the foreign registration server, the home reg- 
istration server authenticates the identity of the foreign 
registration server and also authenticates the identity of 
the end system. If authentication and registration suc- 
ceeds, the home registration server selects an IWF in 
the home network to create an l-xtunnel link between 
the home IWF and the serving IWF (in the foreign WSP). 
The IWF in the home network serves as the anchor point 
for the duration of the PPP session. 
[0083] Once the mobile IP authentication and regis- 
tration phases are over, the various PPP phases will be 
started. At the start of PPP, an L2TP connection is cre- 
ated between the home IWF and requested the ISP/in- 
tranet PPP server. In the PPP authentication phase, 
PPP passwords using PAP or CHAP are exchanged and 
the ISP or intranet PPP server independently authenti- 
cates the identity of the end system. 
[0084] Once this succeeds, the PPP network control 
phase is started. In this phase, an IP address is negoti- 
ated and assigned to the end system by the PPP server 
and the use of TCP/IP header compression is also ne- 
gotiated. When this is complete, the end system is able 
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to send and receive IP packets using PPP to its ISP or 
a corporate intranet. 

[0085] Note that two levels ot authentication are per- 
formed. The mobile IP authentication authenticates the 
identity of the end system to the registration server in 
the home network and the identities of the foreign net- 
work and the home network to each other. To perform 
this function, the foreign agent forwards the end sys- 
tem's registration request using, for example, an IETF 
Radius protocol to a registration server in its local MSG 
in a Radius Access-Request packet. Using the end sys- 
tem's domain name, the foreign registration server de- 
termines the identity of the end system's home network 
and home registration server, and acting as a Radius 
proxy, encapsulates and forwards the request to the end 
system's home registration server. If the foreign regis- 
tration server cannot determine the identity of the end 
1 system's home, it may optionally forward the Radius re- 
quest to a registration server that acts like a broker (e. 
g. one that is owned by a consortium of wireless service 
providers), which can in turn proxy the Radius Access- 
Request to the final home registration server. If the local 
registration server is unable to service the registration 
request locally or by proxying, then it rejects the foreign 
agent's registration request and the foreign agent re- 
jects the end system's registration request. Upon receiv- 
ing the Radius Access-Request, the home registration 
server performs the necessary authentication of the 
identities of the foreign network and the end system, if 
authentication and registration succeeds, the home reg- 
istration server responds with a Radius Access -Re- 
sponse packet to the foreign registration server which 
sends a response to the foreign agent so that a round 
trip can be completed. The registration request is reject- 
ed if the home registration server is unable to comply 
for any reason. 

[0086] The second level of authentication verifies the 
identity of the end system to the intranet or ISP PPP 
server. PPP authentication, separate from mobility au- 
thentication allows the infrastructure equipment to be 
deployed and owned separately from the ISP. 
[0087] FIG. 14 is a ladder diagram showing the reg- 
istration sequence for a roaming end system. It is as- 
sumed that the PPP server and the home I WF are in the 
same server and L2TP is not required. Note the inter- 
actions with accounting servers to start accounting on 
behalf of the registering end system and also directory 
servers to determine the identity of the home registration 
server and to authenticate the end system's identity. 
More information on accounting, billing, roaming (be- 
tween service providers) and settlement will be provided 
below. 

[0088] MAC layer messages (e.g. 802.11 beacon) 
from the user registration agent of the end system initi- 
ate Agent Solicitation. The MAC layer messages are not 
shown for clarity. 

[0089] In FIG. 14, the end system (mobile) initially so- 
licits an advertisement and the foreign agent replies with 



an advertisement that provides the end system with in- 
formation about the network to which the foreign agent 
belongs including a care-of-address of the foreign 
agent. In this case, the network is assumed to be a for- 
5 eign wireless service provider. Then, a user registration 
agent (in the end system) incorporates the information 
about the foreign agent (including the care-of-address) 
and its network into a request and sends the request to 
the foreign agent. The foreign agent, as a proxy regis- 
tration agent, relays the request to the foreign registra- 
tion server (i.e., the registration server for the foreign 
wireless service provider. Then, the foreign registration 
server, recognizing that it is not the home directory, ac- 
cesses the foreign directory server with the FDD in the 
foreign wireless service provider to learn how to direct 
the registration request to the home registration server 
of the wireless service provider to which the end system 
belongs. The foreign registration server responds with 
the necessary forwarding information. Then, the foreign 
registration server encapsulates the end system's reg- 
istration request in a Radius access request and relays 
the encapsulated request to the home registration serv- 
er of the wireless service provider to which the end sys- 
tem belongs. The home registration server accesses the 
home directory server with the HDD of the home regis- 
tration server to learn at least authentication information 
about the foreign service provider. Optionally, the home 
registration server accesses the subscriber's directory 
to learn detail subscriber service profile information (e. 
g. t quality of service options subscribed to, etc.). When 
all parties are authenticated, the home registration serv- 
er sends a start I WF request to the home IWF and PPP 
server. The home IWF and PPP server starts the home 
accounting server and then sends a start IWF response 
to the home registration server. The home registration 
server then sends a Radius access response to the for- 
eign registration server. The foreign registration server 
then sends a start IWF request to the serving IWF serv- 
er. The serving IWF server starts the serving accounting 
server and then sends a start IWF response to the for- 
eign registration server The foreign registration server 
sends a registration reply to the foreign agent, and the 
foreign agent relays the registration reply to the end sys- 
tem. 

[0090] A link control protocol (LCP) configuration re- 
quest is send by the end system through the foreign reg- 
istration server to the home IWF and PPP server. The 
home IWF and PPP server sends an LCP configuration 
acknowledgment through the foreign registration server 
to the end system. 

[0091] Similarly, a password authentication protocol 
(PAP) authentication request is sent to and acknowl- 
edged by the home IWF and PPP server. Alternatively, 
a challenge authentication protocol (CHAP) may be 
used to authenticate. Both protocols may be used to au- 
thenticate or this phase may be skipped. 
[0092] Similarly, an IP configuration protocol (IPCP) 
configure request is sent to and acknowledged by the 
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home IWF and PPP server. 

[0093] The connection to the end system may be ter- 
minated because of any one of the following reasons. 

1. User initiated termination. Under this scenario, 
the end system first terminates the PPP gracefully. 
This includes terminating the PPP network control 
protocol (IPCP) followed by terminating the PPP 
link protocol. Once this is done, the end system de- 
registers from the network followed by termination 
of the radio link to the access point. 

2. Loss of wireless link. This scenario is detected 
by the modem and reported to the modem driver in 
the end system. The upper layers of the software 
are notified to terminate the stacks and notify the 
user. 

3. Loss of connection to the foreign agent This sce- 
nario is detected by the mobility driver in the end 
system. After trying to reestablish contact with a 
(potentially new) foreign agent and failing, the driver 
sends an appropriate notification up the protocol 
stack and also signals the modem hardware below 
to terminate the wireless link. 

4. Loss of connection to the IWF. This is substan- 
tially the same as for loss of connection to the for- 
eign agent. 

5. Termination of PPP by IWF or PPP server. This 
scenario is detected by the PPP software in the end 
system. The end system=s PPP driver is notified of 
this event. It initiates de-registration from the net- 
work followed by termination of the wireless link to 
the access point. 

[0094] End system service configuration refers to the 
concept of configuring the network service for an end 
system based on the subscriber's service profile. The 
subscriber's service profile is stored in a subscriber di- 
rectory. The service profile contains information to ena- 
ble the software to customize wireless data service on 
behalf of the subscriber. This includes information to au- 
thenticate the end system, allow the end system to roam 
and set up connections to the end system's internet 
service provider Preferably this information also in- 
cludes other parameters, like, quality of service. In ad- 
dition to the subscriber directory, a home domain direc- 
tory (HDD) and a foreign domain directory (FDD) are 
used for roaming and for authenticating the foreign and 
home registration servers to each other. The HDD 
stores information about the end system's home net- 
work and the FDD stores information about foreign net- 
works that a subscriber may visit. 
[0095] FIG. 15 shows how these directories map into 
the network architecture and are used during registra- 
tion for an end system that is registering at home. In step 



0 the end system (mobile) solicites an advertisement 
and the foreign agent advertises to provides the end 
system with information about the network to which the 
foreign agent belongs. In this case, the network is the 
s home wireless service provider. In step 1 , user registra- 
tion agent (in the end system) incorporates the informa- 
tion about the foreign agent and its network into a re- 
quest and sends the request to the foreign agent, in step 
2, the foreign agent, as a proxy registration agent, relays 
the request to the home registration server. In step 3, 
the home registration server accesses the HDD of the 
home wireless service provider to learn at least authen- 
tication information. In step 4, the home registration 
server accesses the subscriber directory to learn detail 
subscriber service profile information (e.g., quality of 
service options subscribed to, etc.). In step 5, the home 
registration server notifies the foreign agent of the ac- 
cess response. In steps 6 and 7, the foreign agent no- 
tifies the end system (i.e., mobile) of the registration re- 
ply. 

[0096] FIG . 1 6 shows directory usage for an end sys- 
tem that is registering from a foreign network. In step 0 
the end system (mobile) solicites an advertisement and 
the foreign agent adverstises to provides the end sys- 
tem with information about the network to which the for- 
eign agent belongs. In this case, the network is a foreign 
wireless service provider. In step 1, user registration 
agent (in the end system) incorporates the information 
about the foreign agent and its network into a request 
and sends the request to the foreign agent. In step 2, 
the foreign agent, as a proxy registration agent, relays 
the request to the foreign registration server (i.e., the 
registration server for the foreign wireless service pro- 
vider. In step 3, the foreign registration server accesses 
the HDD of foreign wireless service provider to learn the 
network to which the end system belongs. In step 4, the 
foreign registration server forwards the end system's re- 
quest to thie home registration server of the end sys- 
tem's home wireless service provider. In step 5, the 
home registration server accesses the FDD of the home 
registration server to learn at least authentication infor- 
mation about the foreign service provider. In step 6, the 
home registration server accesses the subscriber's di- 
rectory to learn detail subscriber service profile informa- 
tion (e.g., quality of service options subscribed to, etc.). 
In step 7, the home registration server notifies the for- 
eign registration server of the access response. In step 
8, the foreign registration server forwards to the foreign 
agent the access response. In step 9, the foreign agent 
notifies the end system (i.e., mobile) of the registration 
reply. 

[0097] Protocol handling scenarios for handling bear- 
er data and the associated stacks for transporting bear- 
er data to and from an end system, the protocol stacks 
for the cell architectures using local APs (FIG. 17) and 
remote APs (FIG. 18). 

[0098] FIG. 1 7 shows the protocol stacks for handling 
communications between an end system (in its home 
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network) and a home IWF for End System @ Home. 
FIG. 17 shows the protocol handling for a cell architec- 
ture where the access point and the wireless hub are 
co-located. 

[0099] FIG. 18 shows the protocol handling for a cell 
architecture where the access point is located remotely 
from the wireless hub. As shown, PPP terminates in the 
IWF and the configuration provides direct internet ac- 
cess. The configuration for the case where the PPP 
server is separate from the IWF is described later. 
[0100] In FIG. 18, PPP frames from the end system 
are encapsulated in RLP (radio link protocol) frames 
which are encapsulated at the remote access point in 
MAC frames for communicating with the trunk access 
point (i.e., an access point physically located near the 
wireless hub), the remote access point being coupled to 
the access point by, for example, a wireless trunk). The 
access point functions as a MAC layer bridge and relays 
frames from the air link to the foreign agent in the wire- 
less hub. The foreign agent de-encapsulates the RLP 
frames out of the MAC frames, and using the xtunnel 
protocol, relays the RLP frames to the IWF. A similar, 
albeit reverse, process occurs for transmitting frames 
from the IWF to the end system. 
[0101] If the end system moves to another foreign 
agent, then a new xtunnel be automatically created 
between the new foreign agent and the IWF, so that PPP 
traffic continues to flow between them, without interrup- 
tion. 

[0102] In the remote APcell architecture (FIG. 18) us- 
ing wireless trunks between the remote AP and the trunk 
AP, the air link between the end system and the access 
point may operate at a different frequency (fl) and use 
a different radio technology as compared to the frequen- 
cy (f2) and radio technology of the trunk. 
[0103] FIG. 19 shows the protocol stacks for a roam- 
ing end system. The serving IWF uses of the l-xtunnel 
protocol between the serving IWF and home IWF. The 
rest of the protocol stacks remain unchanged and are 
not shown. 

[0104] The RLP layer uses sequence numbers to 
drop duplicate PPP datagrams and provide in-sequence 
delivery of PPP datagrams between the end system and 
the IWF. It also provides a configurable keep-alive 
mechanism to monitor link connectivity between the end 
system and the IWF. Additionally, in an alternative em- 
bodiment, the RLP layer also provides re-transmission 
and flow control services in order to reduce the overall 
bit error rate of the link between the end system and the 
IWF. The RLP between the end system and the IWF is 
started at the beginning of the session and remains ac- 
tive throughout the session and even across hand-off s. 
[0105] In contrast to the specification in the mobile IP 
RFC (RFC 2003), IP in IP encapsulation is not used for 
tunneling between the foreign agent and the home 
agent. Instead a new tunneling protocol, implemented 
on top of UDP is used. This tunneling protocol is a sim- 
plified version of the L2TP protocol. The reasons for this 



choice are as follows. 

1. The encapsulation protocol specified in RFC 
2003 does not provide flow control or in-sequence 

s delivery of packets. The presently described net- 
work may need these services in the tunnel over the 
backhaul. Flow control may be needed to reduce 
the amount of retransmissions over the air link be- 
cause of packet loss due to flow control problems 
over the network between the base station and the 
MSC or because of flow control problems in the 
base station or the IWF. 

2. By using a UDP based tunneling protocol, the im- 
plementation can be done at the user level and then 
put into the kernel for performance reasons, after it 
has been debugged. 

3. Using RFC 2003, there is no easy way of creating 
tunnels taking into account quality of service and 
load balancing. In order to take QOS into account, 
it should be possible to set up tunnels over links that 
already provide the required QOS. Secondly, using 
RFC 2003, there is no easy way to provide load bal- 
ancing to distribute bearer traffic load over multiple 
links between the base station and the MSC. 

4. In order to implement IP in IP encapsulation as 
specified in RFC 2003, developers require access 
to IP source code. In commercial operating sys- 
tems, source code for the TCP/IP stack is generally 
proprietary to other equipment manufacturers. Pur- 
chasing the TCP/IP stack from a vendor and making 
changes to the IP layer to support mobile IP tun- 
neling would require a developer to continue sup- 
porting a variant version of the TCP/IP stack. This 
adds cost and risk. 

[0106] While it is noted that the tunneling protocol be- 
tween the base station and the IWF is non-standard and 
that the wireless service provider will not be able to mix 
and match equipment from different vendors, the use of 
a non-standard tunneling protocol within a single wire- 
less service provider network is transparent to end sys- 
tems and equipment from other vendors. 
[0107] The new tunneling protocol is based on L2TP 
By itself, L2TP is a heavyweight tunneling protocol so 
that L2TP has a lot of overhead associated with tunnel 
creation and authentication. The new tunneling protocol 
of the present invention has less overhead. The new 
xtunnel protocol has the following features. 

1 . The xtunnel creation adds vendor specific exten- 
sions to Radius Access Request and Radius Ac- 
cess Response messages between the base sta- 
tion and the registration server. These extensions 
negotiate tunnel parameters and to create the tun- 
nel. 
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2. The registration server is able to delegate the ac- 
tual work of tunneling and relaying packets to a dif- 
ferent IP address, and therefore, to a different serv- 
er in the MSC. This permits the registration server 
to do load balancing across multiple IWF servers 
and to provide different QOS to various users. 

3. The xtunnel protocol supports in-band control 
messages for tunnel management. These messag- 
es include echo request/response to test tunnel 
connectivity, disconnect request/response/notify to 
disconnect the tunnel and error notify for error no- 
tifications. These messages are sent over the tun- 
neling media, for example, UDP/IP. 

4. The xtunnel protocol sends pay load data over the 
tunneling media, for example, UDP/IP. The xtunnel 
protocol supports flow control and in-sequence 
packet delivery. 

5. The xtunnel protocol may be implemented over 
media other than UDP/IP for quality of service. 

[0108] The network supports direct internet connec- 
tivity by terminating the PPP in the home IWF and rout- 
ing IP packets from the IWF to the inter net via a router 
using standard IP routing techniques. Preferably, the 
IWF runs RIP, and the router also runs RIP and possibly 
other routing protocols like OSPF. 
[0109] The network supports a first configuration for 
a wireless service provider who is also an internet serv- 
ice provider. In this configuration, the home IWF in the 
MSC also functions as a PPP server. This IWF also runs 
internet routing protocols like RIP and uses a router to 
connect to the internet service providers backbone 
network. 

[0110] The network supports a second configuration 
for a wireless service provider who wishes to allow end 
systems to connect to one or more internet service pro- 
viders, either because the WSP itself is not ISPs, or be- 
cause the WSP has agreements with other ISPs to pro- 
vide access to end users. For example, a wireless serv- 
ice provider may elect to offer network access to an end 
user and may have an agreement with a 3 rd party ISP 
to allow the user who also has an account with the 3 rd 
party ISP to access the ISP from the WSP network. In 
this configuration, the PPP server does not run in the 
home IWF installed at the MSC. Instead, a tunneling 
protocol like L2TP (Layer Two Tunneling Protocol) is 
used to tunnel back to the ISP's PPP server. FIG. 10 
shows the protocol stacks for this configuration for an 
end system that is at home. 

[0111] The location of the home IWF and the ISP PPP 
server remains fixed throughout the PPP session. Also, 
the L2TP tunnel between the IWF and the ISP's PPP 
server remains up throughout the PPP session. The 
physical link between the IWF and the PPP server is via 
a router using a dedicated T1 or T3 or frame relay or 



ATM network. The actual nature of the physical link is 
not important from the point of view of the architecture. 
[0112] This configuration also supports intranet ac- 
cess. For intranet access, the PPP server resides in the 
s corporate intranet and the home IWF uses L2TP to tun- 
nel to it. 

[0113] For a roaming end system, the protocol han- 
dling for intranet or ISP access is as shown in FIG. 20 
with the difference that the roaming end system uses a 
serving IWF to connect to its home IWF. The protocol 
handling between a serving IWF and a home IWF has 
been described earlier. 

[0114] FIG. 21 shows the protocol stacks used during 
the registration phase (end system registration) for a lo- 
cal AP cell architecture. The stack for a remote AP cell 
architecture is very similar. 

[01 15] The scenario shown above is for a roaming end 
system. For an end system at home, there is no foreign 
registration server in the registration path. 
[011 6] Note the mobility agent in the end system. The 
mobility agent in the end system and foreign agent in 
the wireless hub are conceptually similar to the mobile 
IP RFC 2002. The mobility agent handles network errors 
using time-outs and re-trys. Unlike the known protocol 
stacks for bearer data, RLP is not used. The foreign 
agent and the registration servers use Radius over 
UDP/IP to communicate with each other for registering 
the end system. 

[0117] Several aspects of security must be consid- 
ered. The first, authenticating the identities of the end 
system and the foreign/home networks during the wire- 
less registration phase. Second, authenticating the 
identity of the end system with its PPP server during the 
PPP authentication phase. Third, authentication for 
storing accounting data, for billing and for updating 
home domain information. Fourth, encryption of bearer 
traffic transmitted to and from the end system. Fifth, en- 
cryption for exchanging billing information across serv- 
ice provider boundaries. 

[0118] Shared secrets are used to authenticate the 
identity of end systems with their home networks and 
the identity of the home and foreign networks with each 
other during wireless registration. 
[0119] End system authentication uses a 128-bit 
shared secret to create an authenticator for its registra- 
tion request. The authenticator is created using the 
known MD5 message digest algorithm as described in 
the mobile IP RFC 2002, The shared secret is not sent 
in the registration request by the end system. Only the 
authenticator is sent. On receiving the registration re- 
quest from the end system, the home registration server 
re-computes the authenticator over the registration re- 
quest data using the shared secret. If the computed au- 
thenticator value matches the authenticator value sent 
by the end system, the home registration server allows 
the registration process to proceed. If the values do not 
match, the home registration server logs the event, gen- 
erates a security violation alarm and a nak (i.e., a neg- 
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ative acknowledgment) to the request. 
[0120] In the registration reply, the home registration 
server does the same - that is to say, uses the shared 
secret to create an authenticatorforthe registration re- 
ply that it sends to the end system. Upon receiving the 
reply, the end system re-computes the authenticator us- 
ing the shared secret. If the computed value does not 
match the authenticator value sent by the home regis- 
tration server in the reply, the end system discards the 
reply and tries again. 

[0121] These network security concepts are similar to 
the concepts defined in mobile IP RFC 2002. According 
to the RFC, a mobility security association exist between 
each end system and its home network. Each mobility 
security association defines a collection of security con- 
texts. Each security context defines an authentication 
algorithm, a mode, a secret (shared or public-private), 
style of replay protection and the type of encryption to 
use. In the context of the present network, the end sys- 
tem's User-Name (in lieu of the home address) is used 
to identify the mobility security association between the 
end system and its home network. Another parameter, 
called the security parameter index (SPI), is used to se- 
lect a security context within the mobility security asso- 
ciation. In a basic embodiment of the invention, only the 
default mobile IP authentication algorithm (keyed-MD5) 
and the default mode ("prefix + suffix") are supported 
with 128-bit shared secrets. Network users are allowed 
to define multiple shared secrets with their home net- 
works. The mechanism for creating security contexts for 
end users, assigning an SPI to each security context 
and for setting the contents of the security context 
(which includes the shared secret) and for modifying 
their contents are described below. During registration, 
a 128-bit message digest is computed by the end sys- 
tem in prefix + suffix mode using the MD5 algorithm. The 
shared secret is used as the prefix and the suffix for the 
data to be protected in the registration request. The au- 
thenticator thus computed, along with the SPI and the 
User-Name are transmitted in the registration request 
by the end system. Upon receiving the end system's reg- 
istration request, the foreign registration server relays 
the request along with the authenticator and the SPI, 
unchanged to the home registration server. Upon re- 
ceiving the registration request directly from the end 
system or indirectly via a foreign registration server, the 
home registration server uses the SPI and the User- 
Name to select the security context. The home server 
re-computes the authenticator using the shared secret. 
If the computed authenticator value matches the value 
of the authenticator sent in the request by the end sys- 
tem, the user's identity will have been successfully au- 
thenticated. Otherwise, the home registration server 
naks (negatively acknowledges) the registration request 
sent by the end system. 

[0122] The registration reply sent by the home regis- 
tration server to the end system is also authenticated 
using the mobile IP algorithm described above. The SPI 



and the computed authenticator value is transmitted in 
the registration reply message by the home server to 
the end system. Upon receiving the reply, the end sys- 
tem re-computes the authenticator, and if the computed 
s value does not match the transmitted value, it will dis- 
card the reply and retry. 

[0123] The user's end system has to be configured 
with the shared secret and SPIs for all security contexts 
that the user shares with its registration server(s). This 
10 configuration information is preferably stored in a Win 
95 registry for Windows 95 based end systems. During 
registration, this information is accessed and used for 
authentication purposes. 

[0124] In the network, Radius protocols are used by 
*s foreign agent FA to register the end system and to con- 
figure the xtunnel between the wireless hub and the 
home and serving IWFs on behalf of the end system. 
On receiving a registration request from the end system, 
the FA creates a Radius Access-Request packet, stores 
its own attributes into the packet, copies the end sys- 
tem's registration request attributes unchanged into this 
packet and sends the combined request to the registra- 
tion server in the MSC. 

[0125] Radius authentication requires that the Radius 
client (in this case, the FA in the base station) and the 
Radius server (in this case, the registration server in the 
MSC) share a secret for authentication purposes. This 
shared secret is also used to encrypt any private infor- 
mation communicated between the Radius client and 
the Radius server. The shared secret is a configurable 
parameter. The network follows the recommendations 
in the Radius RFC and uses the shared secret and the 
MD5 algorithm for authentication and for encryption, 
where encryption is needed. The Radius-Access Re- 
quest packet sent by the FA contains a Radius User- 
Name attribute (which is provided by the end system) 
and a Radius User-Password attribute. The value of the 
User-Password attribute is also a configurable value 
and encrypted in the way recommended by the Radius 
protocol. Other network specific attributes, which are 
non-standard attributes from the point of view of the Ra- 
dius RFC standards, are encoded as vendor specific 
Radius attributes and sent in the Access-Request pack- 
et. 

[0126] The following attributes are sent by the FA to 
its registration server in the Radius Access-Request 
packet. 

1 . User-Name Attribute. This is the end system's us- 
er-name as supplied by the end system in its regis- 
tration request. 

2. User-Password Attribute, This user password is 
supplied by the base station/wireless hub on behalf 
of the user. It is encoded as described in the Radius 
EFC using the secret shared between the base sta- 
tion and its registration server. 
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3. NAS-Port. This is the port on the base station. 

4. NAS-IP-Address. This is the IP address of the 
base station. 

5. Service-Type. This is framed service. 

6. Framed Protocol. This is a PPP protocol. 

7. Xtunnel Protocol Parameters. These parameters 
are sent by the base station to specify the parame- 
ters necessary to set up the xfunAre/protocol on be- 
half of the end system. This is a vendor-specific at- 
tribute. 

8. AP-IP-Address. This is the IP address of the AP 
through which the user is registering. This is a ven- 
dor-specific attribute, 

9. AP-MAC-Address. This is the MAC address of 
the AP through which the user is registering. This 
is a vendor-specific attribute. 

10. End system's Registration Request. The regis- 
tration request from the end system is copied un- 
changed into this vendor specific attribute. 

[01 27] The following attributes are sent to the FA from 
the registration server in the Radius Access-Response 
packet. 

1 . Sen/ice Type. This is a framed service. 

2. Framed-Protocoi This is a PPP. 

3. Xtunnel Protocol Parameters. These parameters 
are sent by the registration server to specify the pa- 
rameters necessary to set up the xtunnel protocol 
on behalf of the end system. This is a vendor-spe- 
cific attribute. 

4. Home Registration Server's Registration Reply, 
This attribute is sent to the FA from the home reg- 
istration server. The FA relays this attribute un- 
changed to the end system in a registration reply 
packet. If there is a foreign registration server in the 
path, this attribute is relayed by it to the FA un- 
changed. It is coded as a vendor-specific attribute. 

[01 28] To provide service to roaming end systems, the 
foreign network and the home network are authenticat- 
ed to each other for accounting and billing purposes us- 
ing the Radius protocol for authentication and configu- 
ration. This authentication is performed at the time of 
end system registration. As described earlier, when the 
registration server in the foreign network receives a reg- 
istration request from an end system (encapsulated as 
a vendor specific attribute in a Radius-Access Request 



packet by the FA), it uses the end system=s User-Name 
to determine the identity of the end system=s home reg- 
istration server by consulting its home domain directory 
HDD. The following information is stored in home do- 
5 main directory HDD and accessed by the foreign regis- 
tration server in order to forward the end system's reg- 
istration request. 

1 . Home Registration Server IP Address. This is the 
10 IP address of the home registration server to for- 
ward the registration request. 

2. Foreign Registration Server Machine Id. This is 
the machine ID of the foreign registration server in 

is SMTP (simplified mail transfer protocol) format (e. 
g„ machine@fqdn where machine is the name of 
the foreign registration server machine and fqdn is 
the fully qualified domain name of the foreign reg- 
istration server's domain). 

20 

3. Tunneling Protocol Parameters. These are pa- 
rameters for configuring the tunnel between the 
serving I WF and the home I WF on behalf of the end 
system. These include the tunneling protocol to be 

2$ used between them and the parameters for config- 
uring the tunnel, 

4. Shared Secret. This is the shared secret to be 
used for uthentication between the foreign registra- 
nt? tion server and the home registration server. This 

secret is used for computing the Radius User-Pass- 
word attribute in the Radius packet sent by the for- 
eign registration server to the home registration 
server. It is defined between the two wireless serv- 
es ice providers. 

5. User-Password. This is the user password to be 
used on behalf of the roaming end system. This us- 
er password is defined between the two wireless 

40 service providers. This password is encrypted using 
the shared secret as described in the Radius RFC. 

6. Accounting Parameters. These are parameters 
for configuring accounting on behalf of the end sys- 

45 tern that is registering. These parameters are sent 
by the registration server to its I WF for configuring 
accounting on behalf of the end system. 

[0129] Using this information, the foreign registration 
50 server creates a Radius Access-Request, adds its own 
registration and authentication information into the Ra- 
dius Access-Request, copies the registration informa- 
tion sent by the end system unchanged into the Radius 
Access-Request and sends the combined request to the 
55 home registration server. 

[0130] Upon receiving the Radius-Access Request 
from the foreign registration server (for a roaming end 
system) or directly from the FA (for an end system at 
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home), the home registration server consults its own di- 
rectory server for the shared secrets to verify the identity 
of the end system and the identity of the foreign regis- 
tration server in a roaming scenario by re-computing au- 
thenticators. 

[0131] After processing the request successfully, the 
home registration server creates a Radius Access-Ac- 
cept response packet and sends it to the foreign regis- 
tration server if the end system is roaming, or directly to 
the FA from which it received the Radius Access-Re- 
quest. The response contains the registration reply at- 
tribute that the FA relays to the end system. 
[0132] If the request can not be processed success- 
fully, the home registration server creates a Radius Ac- 
cess-Reject response packet and sends it to the forejgn 
registration sewer if the end system is roaming, or di- 
rectly to the FA from which it received the Radius Ac- 
cess-Request. The response contains the registration 
reply attribute that the FA will relays to the end system. 
[0133] In a roaming scenario, the response from the 
home registration server is received by the foreign reg- 
istration server. It is authenticated by the foreign regis- 
tration server using the shared secret. After authenticat- 
ing, the foreign registration server processes the re- 
sponse, and in turn, it generates a Radius response 
packet (Accept or Reject) to send to the FA. The foreign 
registration sewer copies the registration reply attribute 
from the home registration server's Radius response 
packet, unchanged, into its Radius response packet. 
[0134] When the FA receives the Radius Access-Re- 
sponse or Radius Access-Reject response packet, it 
creates a registration reply packet using the registration 
reply attributes from the Radius response, and sends 
the reply to the end system, thus completing the round 
trip registration sequence. 

[0135] Mobile IP standards specifies that replay pro- 
tection for registrations are implemented using time 
stamps, or optionally, using nonces. However, since re- 
play protection using time stamps requires adequately 
synchronized time-of-day clocks between the corre- 
sponding nodes, the present invention implements re- 
play protection during registration using nonces even 
though replay protection using time stamps is manda- 
tory in the Mobile IP standards and the use nonces is 
optional. However, replay protection using time stamps 
as an alternative embodiment is envisioned. 
[0136] The style of replay protection used between 
nodes is stored in the security context in addition to the 
authentication context, mode, secret and type of encryp- 
tion. 

[0137] The network supports the use of PPP PAP 
(password authentication) and CHAP (challenge au- 
thenticated password) between the end system and its 
PPP server. This is done independently of the mobile IP 
and Radius based authentication mechanisms de- 
scribed earlier. This allows a private intranet or an ISP 
to independently verify the identity of the user. 
[0138] Authentication for accounting and directory 



services is described below with respect to accounting 
security. Access to directory servers from network 
equipment in the same MSG need not be authenticated. 
[01 39] The network supports encryption of bearer da- 
5 ta sent between the end system and the home I WF. End 
systems negotiate encryption to be on or off by selecting 
the appropriate security context. Upon receiving the reg- 
istration request, the home registration server grants the 
end system's request for encryption based upon the se- 
curity context. In addition to storing the authentication 
algorithm, mode, shared secret and style of replay pro- 
tection, the security context is also used to specify the 
style of encryption algorithm to use. If encryption is ne- 
gotiated between the end system and the home agent, 
then the complete PPP frame is so encrypted before en- 
capsulation in RLP 

[01 40] The I WF, the accounting server and the billing 
system are part of the same trusted domain in the MSC. 
These entities are either connected on the same LAN 
or part of a trusted intranet owned and operated by the 
wireless sen/ice provider. Transfer of accounting statis- 
tics between the iWF and the accounting server and be- 
tween the accounting server and the customer's billing 
system need not be encrypted. 
[0141] The network makes it more difficult to monitor 
the location of the end system because it appears that 
all PPP frames going to and from the end system go 
through the home IWF regardless of the actual location 
of the end system device. 

[0142] Accounting data is collected by the serving 
IWF and the home IWF in the network. Accounting data 
collected by the serving IWF is sent to an accounting 
server in the serving IWF's MSC. Accounting data col- 
lected by the- home IWF is sent to an accounting server 
in the home IWF's MSC. The accounting data collected 
by the serving IWF is used by the foreign wireless serv- 
ice provider for auditing and for settlement of bills across 
wireless service provider boundaries (to support roam- 
ing and mobility). The accounting data collected by the 
home IWF is used for billing the end user and also for 
settlement across wireless service provider boundaries 
to handle roaming and mobility. 
[0143] Since all data traffic flows through the home 
IWF, regardless of the end system's location and the for- 
eign agent's location, the home IWF has all the informa- 
tion to generate bills for the customer and also settle- 
ment information for the use of foreign networks. 
[0144] The serving IWF and the home IWF preferably 
use the Radius accounting protocol for sending ac- 
counting records for registered end systems. The Radi- 
us accounting protocol is as documented in a draft IETF 
RFC. For the present invention, the protocol has to be 
extended by adding vendor specific attributes for the 
network and by adding check-pointing to the Radius Ac- 
counting protocol. Check-pointing in this context refers 
to the periodic updating of accounting data to minimize 
risk of loss of accounting records. 
[0145] The Radius accounting protocol runs over 
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U DP/IP and uses re-trys based on acknowledgment and 
time outs. The Radius accounting client (serving IWFs 
or home IWFs) send UDP accounting request packets 
to their accounting servers which send acknowledg- 
ments back to the accounting clients. 
[0146] In the network, the accounting clients (serving 
IWF and the home IWF) emit an accounting start indi- 
cation at the start of the user's session and an account- 
ing stop indication at the end of the user's session. In 
the middle of the session, the accounting clients emit 
accounting checkpoint indications. In contrast, the Ra- 
dius accounting RFC does not specify an accounting 
checkpoint indication. The software of the present in- 
vention creates a vendor specific accounting attribute 
for this purpose. This accounting attribute is present in 
ail Radius Accounting-Request packets which have Ac- 
ct-Status-Type of Start (accounting start indications). 
The value of this attribute is used to convey to the ac- 
counting server whether the accounting record is a 
check-pointing record or not. Check-pointing account- 
ing reports have a time attribute and contain cumulative 
accounting data from the start of the session. The fre- 
quency of transmitting check-point packets is configura- 
ble in the present invention. 

[0147] The serving IWF and the home IWF are con- 
figured by their respective registration servers for con- 
necting to their accounting servers during the registra- 
tion phase. The configurable accounting parameters in- 
clude the IP address and UDP port of the accounting 
server, the frequency of check-pointing, the session/ 
multi-session id and the shared secret to be used be- 
tween the accounting client and the accounting server. 
[0148] The network records the following accounting 
attributes for each registered end system. These ac- 
counting attributes are reported in Radius accounting 
packets at the start of the session, at the end of the ses- 
sion and in the middle (check-point) by accounting cli- 
ents to their accounting servers. 

1. User Name. This is like the Radius User-Name 
attribute discussed above. This attribute is used to 
identify the user and is present in all accounting re- 
ports. The format is "use^domain" where domain 
is the fully qualified domain name of the user's 
home. 

2. NAS IP Address. This is like the Radius NAS-IP- 
Address attribute discussed above. This attribute is 
used to identify the IP address of the machine run- 
ning the home IWF or the serving IWF. 

3. Radio Port. This attribute identifies the radio port 
on the access point providing service to the user. 
This attribute is encoded as a vendor specific at- 
tribute. 

4. Access Point IP Address. This attribute identifies 
the IP address of the access point providing service 



to the user. This attribute is encoded as a vendor 
specific attribute. 

5. Service Type. This is like the Radius Service- 
5 Type attribute described above. The value of this 

attribute is Framed. 

6. Framed Protocol. This is like the Radius Framed- 
Protocol attribute described above. The value of 

io this attribute is set to indicate PPP. 

7. Accounting Status Type. This is like the Radius 
Acct-Status-Type attribute described above. The 
value of this attribute may be Start to mark the start 

is of a user's session with the Radius client and Stop 
to mark the end of the user's session with the Ra- 
dius client. For accounting clients, the Acct-Status- 
Type/Start attribute is generated when the end sys- 
tem registers. The Acct-Status-type/Stop attribute 
20 js generated when the end system de-registers for 
any reason. For checkpoints, the value of this at- 
tribute is also Start and the Accounting Checkpoint 
attribute is also present. 

2S 8. Accounting Session Id. This is like the Radius Ac- 
ct-Session-ld described above. In a roaming sce- 
nario, this session id is assigned by the foreign reg- 
istration server when the end system issues a reg- 
istration request. It is communicated to the home 
30 registration server by the foreign registration server 
during the registration sequence. The home net- 
work and the foreign network both know the Acct- 
Session-ld attribute and are able to emit this at- 
tribute while sending accounting records to their re- 
35 spective accounting servers. In a "end system-at- 
home 0 scenario, this attribute is generated by the 
home registration server. The registration server 
communicates the value of this attribute to the IWF 
which emits it in all accounting records. 

40 

9. Accounting Multi-Session Id. This is like the Ra- 
dius Acct-Mutti-Session-ld discussed above. This id 
is assigned by the home registration server when a 
registration request is received from a FA directly or 
45 via a foreign registration server on behalf of an end 
system. It is communicated to the foreign registra- 
tion server by the home registration server in the 
registration reply message. The registration server 
(s) communicates the value of this attribute to the 
so IWF(s) which emit it in all accounting records. 

[0149] With true mobility added to the architecture, 
the id is used to relate together the accounting records 
from different IWFs for the same end system if the end 
55 system moves from one IWF to another. For hand-offs 
across IWF boundaries, the Acct-Session-ld is different 
for accounting records emanating from different IWFs. 
However, the Acct-Multi-Session-ld attribute is the 
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same for accounting records emitted by all IWFs that 
have provided service to the user. Since the session id 
and the multi-session id are known to both the foreign 
network and the home network, they are able to emit 
these attributes in accounting reports to their respective 
accounting servers. With the session id and the multi- 
session id, billing systems are able to correlate account- 
ing records across I WF boundaries in the same wireless 
service provider and even across wireless service pro- 
vider boundaries. 

1 . Accounting Delay Time. See Radius Acct-Delay- 
Time attribute. 

2. Accounting Input Octets. See Radius Acct-lnput- 
Octets. This attribute is used to keep track of the 
number of octets sent by the end system (input to 
the network from the end system). This count is 
used to track the PPP frames only. The air link over- 
head, or any overhead imposed by RLP, etc. and is 
not counted. 

3. Accounting Output Octets. See Radius Acct-Out- 
put-Octets. This attribute is used to keep track of 
the number of octets sent to the end system (output 
from the network to the end system). This count is 
used to track the PPP frames only. The air link over- 
head, or any overhead imposed by RLP, etc. and is 
not counted. 

4. Accounting Authentic. See Radius Acct-Authen- 
tic attribute. The value of this attribute is Local or 
Remote depending on whether the serving IWF or 
the home IWF generates the accounting record. 

5. Accounting Session Time. See Radius Acct-Ses- 
sion-Time attribute. This attribute indicates the 
amount of time that the user has been receiving 
service. If sent by the serving IWF, this attribute 
tracks the amount of time that the user has been 
receiving service from that serving IWF. If sent by 
the home IWF, this attribute tracks the amount of 
time that the user has been receiving service from 
the home IWF. 

6. Accounting Input Packets. See Radius Acct-ln- 
put-Packets attribute. This attribute indicates the 
number of packets received from the end system. 
For a serving IWF, this attribute tracks the number 
of PPP frames input into the serving IWF from an 
end system. For a home IWF, this attribute tracks 
the number of PPP frames input into the home IWF 
from an end system. 

7. Accounting Output Packets. See Radius Acct- 
Output-Packets attribute. This attribute indicates 
the number of packets sent to the end system. For 
a serving IWF, this attribute tracks the number of 



PPP frames output by the serving IWF to the end 
system. For a home IWF, this attribute tracks the 
number of PPP frames sent to the end system from 
the home IWF. 

5 

8. Accounting Terminate Cause. See Radius Acct- 
Terminate-Cause attribute. This attribute indicates 
the reason why a user session was terminated. In 
addition, a specific cause code is also present to 

10 provide additional details. This attribute is only 
present in accounting reports at the end of the ses- 
sion. 

9. Network Accounting Terminate Cause. This at- 
'5 tribute indicates a detailed reason for terminating a 

session. This specific attribute is encoded as a ven- 
dor specific attribute and is only reported in a Radi- 
us Accounting attribute at the end of session. The 
standard Radius attribute Acct-Terminate-Cause is 
20 also present. This attribute provides specific cause 
codes, not covered by the Acct-Terminate-Cause 
attribute. 

10. Network Air link Access Protocol. This attribute 
25 indicates the air link access protocol used by the 

end system. This attribute is encoded as a vendor 
specific attribute. 

■ 11. Network Backhaul Access Protocol. This at- 
30 tribute indicates the backhaul access protocol used 
by the access point to ferry data to and from the end 
system. This attribute is encoded as a vendor spe- 
cific attribute. 

55 1 2. Network Agent Machine Name. This attribute is 
the fully qualified domain name of the machine run- 
ning the home IWF or the serving IWF. This specific 
attribute is encoded in vendor specific format. 

40 1 3. Network Accounting Check-point. Since the Ra- 
dius accounting RFC does not define a check-point 
packet, the present network embodiment uses a 
Radius accounting start packet with this attribute to 
mark a check-point. The absence of a check-point 

45 attribute means a conventional accounting start 
packet. The presence of this attribute in a account- 
ing start packet means a accounting check-point 
packet. Accounting stop packets do not have this 
attribute. 

so 

[0150] In the preferred embodiment, every account- 
ing packet and the corresponding reply must be authen- 
ticated using MD5 and a shared secret. The IWFs are 
configured with a shared secret that are used by them 
55 for authentication during communication with their Ra- 
dius accounting server. The shared secrets used by the 
IWFs for communicating with accounting servers are 
stored in the home/foreign domain directory located in 
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* the MSC. The shared secrets for accounting security are 
communicated to the IWFs by their registration servers 
during the end system registration sequence. 
[0151] The accounting server software runs in a com- 
puter located in the MSC. The role of the accounting 5 
server in the system is to collect raw accounting data 
from the network elements (the home and the serving 
IWFs), process the data and store it for transfer to the 
wireless service provider's billing system. The account- 
ing server does not include a billing system. Instead, it io 
includes support for an automatic or manual accounting 
data transfer mechanism. Using the automatic account- 
ing data transfer mechanism, the accounting server 
transfers accounting records in AMA billing format to the 
customer's billing system over a TCP/IP transport. For is 
this purpose, the system defines AMA billing record for- 
mats for packet data. Using the manual transfer mech- 
anism, customers are able to build a tape to transfer ac- 
counting records to their billing system. In order to build 
the tape to their specifications, customers are provided 20 
with information to access accounting records so that 
they may process them before writing them to tape. 
[0152] In FIG. 22, the raw accounting data received 
by the accounting server from the home or serving IWFs 
are processed and stored by the accounting server. The 2s 
processing done by the accounting server includes fil- 
tering, compression and correlation of the raw account- 
ing data received from the IWF. A high availability file 
server using dual active/standby processors and hot 
swappable RAID disks is used for buffering the account- 30 
ing data while it is transiting through the accounting 
server. 

[0153] The accounting server delays processing of 
the raw accounting data until an end system has termi- 
nated its mobile IP session. When an end system ter- 35 
minates its session, the accounting server processes 
the raw accounting data that it has collected for the ses- 
sion and stores an accounting summary record in a SQL 
database. The accounting summary record stored in the 
SQL data base points to an ASN.1 encoded file. This ^ 
file contains detailed accounting information about the 
end system's session. The data stored in the accounting 
server is then transferred by the billing data transfer 
agent to the customer's billing system. Alternatively, the 
wireless service provider may transfer the accounting 45 
data from the SQL database and/or the ASN.1 encoded 
file to the billing system via a tape. The data base 
scheme and the format of the ASN.1 encoded file are 
documented and made available to customers for this 
purpose. If the volume of processed accounting data so 
stored in the accounting system exceeds a high water 
mark, the accounting server generates an NMS alarm. 
This alarm is cleared when the volume of data-stored in 
the accounting server falls below a low water mark. The 
high and low water marks for generating and clearing 55 
the alarm are configurable. The accounting server also 
generates an NMS alarm if the age of the stored ac- 
counting data exceeds a configurable threshold. Con- 



versely, the alarm is cleared, when the age of the ac- 
counting data falls below the threshold. 
[01 54] The subscriber directory is used to store infor- 
mation about subscribers and is located in the home net- 
work. The home registration server consults this direc- 
tory during the registration phase to authenticate and 
register an end system. For each subscriber, the sub- 
scriber directory stores the following information. 

1 . User-Name. This field in the subscriber record 
will be in SMTP format (e.g., user@fqdn) where the 
user sub-field will identify the subscriber in his or 
her wireless home domain and the fqdn sub-field 
will identify the wireless home domain of the sub- 
scriber. This field is sent by the end system in its 
registration request during the registration phase. 
This field is assigned by the wireless service pro- 
vider to the subscriber at the time of subscription to 
the network service. This field is different than the 
user name field used in PPP. 

2. Mobility Security Association. This field in the 
subscriber record contains the mobility security as- 
sociation between the subscriber and his or her 
home network. As described above, a mobility se- 
curity association exists between each subscriber 
and its home registration server. The mobility secu- 
rity association defines a collection of security con- 
texts. Each security context defines an authentica- 
tion algorithm, an authentication mode, a shared 
secret, style of replay protection and the type of en- 
cryption (including no encryption) to use between 
the end system and its home server. During regis- 
tration, the home registration server retrieves infor- 
mation about the subscriber's security context from 
the subscriber directory using the User-Name and 
the security parameter index (SIP) supplied by the 
end system in its registration request. The informa- 
tion in the security context is used for enforcing au- 
thentication, encryption and replay protection dur- 
ing the session. The mobility security association is 
created by the wireless service provider at the time 
of subscription. It is up to the wireless service pro- 
vider to permit the subscriber to modify this associ- 
ation either by calling up a customer service repre- 
sentative or by letting subscribers access to a se- 
cure Web site. The Web site software will export 
web pages which the wireless service provider may 
make accessible to subscribers from a secure web 
server. In this way, subscribers are able to view/ 
modify the contents of the mobility security associ- 
ation in addition to other subscriber information that 
the service provider may make accessible. 

3. Modem MAC Address. This field contains the 
MAC address of the modem owned by the subscrib- 
er. In addition to the shared secret, this field is used 
during registration to authenticate the user. It is pos- 
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sible to turn off MAC address based authentication 
on a per user basis. The MAC address is commu- 
nicated to the home registration server during reg- 
istration. 

4. Enable MAC Address Authentication. This field 
is used to determine if MAC address based authen- 
tication is enabledor disabled. II enabled, the home 
registration server checks the MAC address of the 
registering end system against this field to validate 

, the end system's identity. If disabled, then no check- 
ing is done. 

5. Roaming Enabled Flag. If this field is set to ena- 
bled, then the end system is allowed to roam to for- 
eign networks. If this field is disabled, then the end 
system is not permitted to roam to foreign networks. 

6. Roaming Domain List. This field is meaningful on^ 
ly if the Roaming Enabled Flag is set to enabled. 
This field contains a list of foreign domains that the 
end system is allowed to roam to. When the con- 
tents of this list is null and the Roaming Enabled 
Flag is set to enabled, the end system is allowed to 
roam freely. 

7. Sen/ice Enable/Disable Flag. This field may be 
set to disabledby the system administrator to disa- 
ble service to a subscriber. If this field is disabled, 
then the subscriber is be permitted to register for 
service. If the subscriber is registered and the value 
of this field is set to disabled, then the subscriber's 
end system is immediately disconnected by the net- 
work. 

8. Internet Sen/ice Provider Association. This field 
contains information about the subscriber's internet 
service provider. This information is used by the 
IWF during the PPP registration phase to perform 
authentication with the internet service provider on 
behalf of the end system and also to create a L2TP 
tunnel between the IWF and the internet sen/ice 
provider's PPP server. This field contains the iden- 
tity of the subscriber's ISP. The IWF uses this infor- 
mation to access the ISP directory for performing 
authentication and setting up the L2TP tunnel on 
behalf of the end system. 

9. Subscriber's Name & Address Information. This 
field contains the subscriber's name, address, 
phone, fax, e-mail address, etc. 

[0155] The home domain directory (HDD) is used by 
the registration server to retrieve parameters about the 
end system to complete registration on behalf of the end 
system. Using this information, the registration server 
determines if the end system is registering at home or 
if the end system is a roaming end system. In the former 



case, the registration server assumes the role of a home 
registration server and proceed with end system regis- 
tration. In the latter case, the registration server as- 
sumes the role of a foreign registration server and, act- 

s ing as a Radius proxy, it forwards the request to the real 
home registration server whose identity it gets from this 
directory. For roaming end system, the parameters 
stored in the HDD include the IP address of the home 
registration server, the home-foreign shared secret, the 

10 home-serving IWF tunnel configuration etc. The HDD is 
located in the MSC. 

[0156] The following information is stored in the HDD. 

1. Home Domain Name. This field is used as the 
15 key to search the HDD for an entry that matches the 

fully qualified home domain name provided by the 
end system in its registration request. 

2. Proxy Registration Request This field is used by 
the registration server to determine if it should act 
as a foreign registration server and proxy the end 
system's registration request to the real home reg- 
istration server. 

3. Home Registration Server DNS Name. If the 
proxy registration requesting is TRUE, this field is 
used to access the DNS name of the real home reg- 
istration server. Otherwise, this field is ignored. The 
DNS name is translated to an IP address by the for- 
eign registration server. The foreign registration 
server uses the I P address to relay the end system's 
registration request. 

4. Foreign Domain Name. If the proxy registration 
request flag is TRUE, this field is used to identify 
the foreign domain name to the end system's home 
registration server. Otherwise, this field is ignored. 
The foreign registration server uses this information 
to create the foreign server machine id in SMTP for- 
mat, for example, machine@fqdn. This machine id 
is sent to the home registration server by the foreign 
registration server in the Radius-Access Request. 

5. Shared Secret. If the proxy registration request 
flag is TRUE, the shared secret is used between the 
foreign and home registration servers to authenti- 
cate their identity with each other. Otherwise this 
field is ignored. 

6. Tunneling Protocol Parameters. This field is used 
to store parameters to configure the tunnels to pro- 
vide service to the end system. For an end system 
at home, this includes information on tunnel param- 
eters between the base station and the home IWF 
and from the home IWF to the PPP server. For a 
roaming end system, this includes tunneling param- 
eters from the base station to the serving IWF and 
from the serving IWF to the home IWF. At a mini- 
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mum, for each tunnel, this field contains the type of 
tunneling protocol to use and any tunneling protocol 
specific parameters. For example, this field may 
contain the identifier for the tunneling protocol L2TP 
and any additional parameters required to configure 
the L2TP tunnel between the IWF and its peer. 

7. Accounting Server Association. This field is used 
to store information needed by the IWF to generate 
accounting data on behalf of the end system. It con- 
tains the name of the accounting protocol (e.g. RA- 
DIUS), the DNS name of the accounting server and 
additional parameters specific to the accounting 
protocol like the UDP port number, the shared se- 
cret that the IWF must use in the Radius Accounting 
protocol, the frequency of check-pointing, the seed 
for creating the session/multi-session id, etc. The 
accounting server's DNS name is translated to the 
accounting server's IP address, which is sent to the 
IWF. 

[01 57] For wireless service providers that have roam- 
ing agreements with each other, the HDD is used for 
authentication and to complete the registration process. 
If an end system roams from its home network to a for- 
eign network, the foreign registration server in that net- 
work consults the HDD in its MSC to get information 
about the visiting end system's home registration and to 
authenticate the home network before it provides serv- 
ice to the visiting end system. 
[0158] The software for home domain directory man- 
agement preferably provides a graphical user interface 
(GUI) based HDD management interface for system ad- 
ministrators. Using this GUI, system administrators are 
able to view and update entries in the HDD. This GUI is 
not intended for use by foreign wireless network service 
providers to perform remote updates based on roaming 
agreements. It is only intended for use by trusted per- 
sonnel of the home wireless service provider operating 
behind fire walls. 

[0159] The foreign domain directory (FDD) provides 
functionality that is the reverse of the home domain di- 
rectory. The FDD is used by the home registration server 
to retrieve parameters about the foreign registration 
server and the foreign network in order to authenticate 
the foreign network and create a tunnel between a serv- 
ing IWF and a home IWF. These parameters include the 
home-foreign shared secret, the home I WF-serving IWF 
tunnel configuration, etc. The FDD is preferably located 
in the home registration server's MSC. The FDD is used 
by home registration servers for registering roaming end 
systems. 

[0160] The following information will be stored in the 
FDD. * 

1. Foreign Domain Name. This field is used as the 
key to search the FDD for an entry that matches the 
fully qualified domain name of the foreign registra- 



tion server relaying the registration request. 

2. Shared Secret This is the shared secret used 
between the foreign and home registration servers 

s to authenticate their identity mutually with each oth- 
er. 

3. Home IWF-Serving IHF Tunneling Protocol Pa- 
rameters. This field is used to store parameters to 

io configure the tunnel between the home IWF and the 
serving IWF. At a minimum, this field contains the 
type of tunneling protocol to use and any tunneling 
protocol specific parameters. For example, this field 
' may contain the identifier for the tunneling protocol 
*5 L2TP and any additional parameters required to 
configure the L2TP tunnel between the serving IWF 
and the home IWF. 

4. Accounting Server Association. This field is used 
20 to store information needed by the home IWF to 

generate accounting data on behalf of the end sys- 
tem. It contains the name of the accounting protocol 
(e.g. RADIUS), the DNS name of the accounting 
server and additional parameters specific to the ac- 
25 counting protocol like the UDP port number, the 
shared secret that the IWF must use in the Radius 
Accounting protocol, the frequency of check-point- 
ing, the seed for creating the session/multi-session 
id, etc. The accounting server's DNS name istrans- 
30 lated to the accounting server's IP address, which 
is sent to the foreign agent. 

[0161] For wireless service providers that have roam- 
ing agreements with each other, the FDD is used to do 

35 authentication and complete the registration process. If 
an end system roams from its home network to a foreign 
network, the registration server in the home network 
consults the FDD in its MSC to get information and au- 
thenticate the foreign network providing service to the 

40 end system. 

[0162] The foreign domain directory management 
software provides a graphical user interface (GUI) 
based FDD management interface for system adminis- 
trators. Using this GUI, system administrators are able 

45 to view and update entries in the FDD. This GUI is not 
intendedfor use by foreign wireless network service pro- 
viders to perform remote updates based on roaming 
agreements. It is only intended for use by trusted per- 
sonnel of the home wireless service provider operating 

50 behind firewalls. 

[0163] The internet service provider directory (ISPD) 
is used by the home IWF to manage connectivity with 
ISPs that have service agreements with the wireless 
service provider so that subscribers may access their 

55 ISPs using the network. For each subscriber, the sub- 
scriber directory has an entry for the subscriber's ISP. 
This field points to an entry in the ISPD. The home IWF 
uses this information to set up the connection to the ISP 
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* on behalf of the subscriber. 

[01 64] The network architecture supports roaming. In 
order for roaming to work between wireless service pro- 
viders, the architecture must support the setting up of 
roaming agreements between wireless service provid- 
ers. This implies two things: (1 ) updating system direc- 
tories across wireless service providers and (2) settle- 
ment of bills between service providers. 
[01 65] In order to allow subscribers access to internet 
service providers, the architecture supports roaming 
agreements with internet service providers. This implies 
that the architecture must be able to send data to and 
receive data from ISP PPP servers (i.e., that support in- 
dustry standard protocols like PPP, L2TP and Radius). 
It also implies that the architecture handles directory up- 
dates for ISP access and settlement of bills with ISPs. 
[0166] When roaming agreements are established 
between two wireless service providers, both providers 
have to update their home and foreign domain directo- 
ries in order to support authentication and registration 
functions for end systems visiting their networks from 
the other network. At a minimum, the architecture of the 
present embodiment supports manual directory up- 
dates. When a roaming agreement is established be- 
tween two wireless service providers, then the two par- 
ties to the agreement exchange information for populat- 
ing their home and foreign domain directories. The ac- 
tual updates of the directories is done manually by the 
personnel of the respective service providers. If later, 
the information in the home and foreign domain direc- 
tories needs to be updated, the two parties to the agree- 
ment exchange the updated information and then man- 
ually apply their updates to the directories. 
[0167] In an alternative embodiment, the directory 
management software incorporates developing stand- 
ards in the IETF to enable roaming between internet 
service providers and to enable ISPs to automatically 
manage and discover roaming relationships. This 
makes manual directory management no longer neces- 
sary. The network system automatically propagates 
roaming relationships, and discovers them, to authenti- 
cate and register visiting end systems. 
[0168] At a minimum, the network architecture just 
processes and stores the accounting data and makes 
the data available to the wireless service provider's bill- 
ing system. It is up to the billing system to handle set- 
tlement of bills for roaming. 

[0169] In an alternative embodiment, developing 
standards in the IETF to handle distribution of account- 
ing records between internet service providers are in- 
corporated into the network architecture to enable ISPs 
to do billing settlement for roaming end systems. 
[0170] The system software supports access to ISPs 
and private intranets by supporting L2TP between the 
home IWF and the ISPs or intranet PPP server. The in- 
ternet service provider directory contains information 
useful to the IWF for creating these tunnels. As access 
agreements between the wireless service provider and 



internet service providers are put in place, this directory 
is updated manually by the wireless service provider's 
personnel. Automatic updates and discovery of access 
relationships between the wireless sen/ice provider and 

5 internet service providers are presently contemplated 
and implemented as the internet standards evolve. 
While accessing an internet service provider, the sub- 
scriber receives two bills - one from the wireless service 
provider for the use of the wireless network and the sec- 

10 ond from the internet service provider Although com- 
mon billing that combines both types of charges is not 
handled by the minimum embodiment software, it is con- 
templated that the software will take advantage of inter- 
net standards for billing settlement as they evolve so 

is that subscribers may receive a common bill based on 
roaming agreements between the ISP and wireless 
service providers. 

[0171] The system includes a element management 
system for managing the network elements. From the 

20 element manager, system administrators perform con- 
figuration, performance and fault/alarm management 
functions. The element management applications run 
on top of a web browser. Using a web browser, system 
administrators manage the network from anywhere that 

25 they have TCP/IP access. The element manager also 
performs an agent role for a higher level manager. In 
this role it exports an SNMP Ml B for alarm and fault mon- 
itoring. 

[0172] A higher level SNMP manager is notified of 
30 alarm conditions via SNMP traps. The higher level 
SNMP manager periodically polls the element manag- 
ers MIB for the health and status of the network. Sys- 
tem management personnel at the higher level manager 
are able to view an icon representation of the network 
36 and its current alarm state. By pointing and clicking on 
the network element icon, systems management per- 
sonnel execute element management applications us- 
ing a web browser and perform more detailed manage- 
ment functions. 
40 [0173] Inside the network, management of the physi- 
cal and logical network elements is performed using a 
combination of the SNMP protocol and internal manage- 
ment application programming interfaces. Applications 
in the element manager use SNMP or other manage- 
rs ment APIs to perform network management functions. 
[01 74] Architecturally, the element management sys- 
tem includes of two distinct sets of functional elements. 
The first set of functional elements, including the con- 
figuration data server, performance data monitor and 
50 health/status monitor and network element recovery 
software, executes on an HA server equipped with RAI D 
disks. The second set of functional elements, including 
the management applications, executes on a dedicated, 
non-HA management system. Even if the element man- 
55 ager system becomes non-operational, the network el- 
ements continue to be able to run and report alarms and 
even be able to recover from fault conditions. However, 
since all the management applications execute in the 
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non -HA element manager, if the element manager goes 
down, then recovery actions requiring human interven- 
tion are not possible until the element manager be- 
comes operational. 

[0175] The wireless hubs (WHs) in the base stations 
are typically owned by a wireless service provider 
(WSP), and they are connected to the WSPs registra- 
tion server (RS) either via point-to-point links, intranets 
or the Internet. The WSP's registration server is typically 
a software module executing on a processor to perform 
certain registration functions. Inter-working function 
units (IWF units) are typically software modules execut- 
ing on a processor to perform certain interfacing func- 
tions. IWF units are typically connected to the registra- 
tion servers via intranets/WAN, and the IWF units 3re 
typically owned by the WSP. However, the IWF units 
need not be located within the same LAN as the regis- 
tration servers. Typically, accounting and directory serv- 
ers (also software modules executing on a processor) 
are connected to the registration servers via a LAN in 
the service provider's Data Center (e.g., a center includ- 
ing one or more processors that hosts various servers 
and other software modules). Traffic from the end sys- 
tem is then routed via a router (connected to the LAN) 
to the public Internet or to an ISP's intranet. The regis- 
tration server located in a foreign WSP's network is re- 
ferred to as the foreign registration server (FRS), and 
the registration server located in the end system's home 
network (where the mobile purchases its service) is re- 
ferred to as the home registration server (HRS). The in- 
ter-working function unit in the home network is referred 
to as the home IWF while the inter-working function unit 
in the foreign network (i.e., the network the end system 
is visiting) is referred to as the serving IWF. 
[0176] For fixed wireless service (i.e., a non-moving 
end system), an end system may registerfor service on 
the home network from the home network (e.g., at home 
service) or from a foreign network (e.g., roaming serv- 
ice). The end system receives an advertisement sent by 
an agent (e.g., an agent function implemented in soft- 
ware) in the wireless hub via the access point. There 
are both MAC-layer registration as well as network-layer 
registration to be accomplished. 
[0177] For end systems at home (FIG. 23), the net- 
work layer registration (like a local registration) make's 
known to the home registration server the wireless hub 
to which the end system is currently attached. An IWF 
in the end system's home network will become the an- 
chor or home IWF. Thus, PPP frames to and from the 
end system travel via the wireless hub to the home IWF 
in the home network. If the end system is at home, the 
home IWF is connected to the wireless hub via an XTun- 
nel protocol. 

[0178] For roaming wireless service (FIG. 24), the for- 
eign registration server determines the identity of the 
home network of the roaming end system during the reg- 
istration phase. Using this information, the foreign reg- 
istration server communicates with the home registra- 



tion server to authenticate and register the end system. 
The foreign registration server then assigns a serving 
IWF, and an l-XTunnel protocol connection is estab- 
lished between the home IWF and the serving IWF for 
s the roaming end system. The serving IWF relays frames 
between the wireless hub and the home IWF. From the 
home IWF, data is sent to a PPP server (i.e., point-to- 
point protocol server) which may reside in the same IWF. 
However, if the data is to go to a corporate intranet or 
an ISP's intranet that has its own PPP server, the data 
is sent to the separate PPP server via the L2TP protocol. 
The separate server is typically owned and operated by 
an Internet service provider who is different from the 
wireless service provider. For the duration of the ses- 
sion, the locations of the home IWF and PPP server re- 
main fixed. The MAC layer registration can be combined 
with the network registration to economize on the over- 
head of separate communications for MAC layer and 
network layer registration; however, it may be advanta- 
geous to not combine these registration processes so 
that the WSP's equipment will be interoperable with oth- 
er wireless networks that supports pure IETF Mobile-IR 
[0179] Registration sets up three tables. Table 1 is as- 
sociated with each access point, and Table 1 identifies 
each connection (e.g., each end system) by a connec- 
tion id (CID) and associates the connection id with a par- 
ticular wireless (WM) modem address (i.e., the address 
of the end system or end system). Table 2 is associated 
with each wireless hub (WH), and Table 2 associates 
each connection id with a corresponding wireless mo- 
dem address, access point and XTunnei id (XI D). Table 
3 is associated with each inter-working function (IWF), 
and Table 3 associates each connection id with a corre- 
sponding wireless modem address, wireless hub ad- 
dress, XTunnei id and IP port (IP/port). The entries de- 
scribed for these tables are described to include only 
relevant entries that support the discussion of mobility 
management. In reality, there are other important fields 
that need to be included as well. 
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Table 2: (continued) 
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[0180] The protocol stacks for dial-up users at home 
in a network as well as roaming users are illustrated in 
FIGS. 25-28. FIG. 25 depicts protocol stacks used for 
direct internet access by a fixed (i.e., non-moving) end 
system at home where a PPP protocol message termi- 
nates in the home IWF (typically collocated with the 
wireless hub) which relays message to and from an IP 
router and from there to the public internet. FIG. 26 de- 
picts protocol stacks used for remote intranet access (i. 
e., either private corporate nets or an ISP) by a fixed (i. 
e., non-moving) end system at home where a PPP pro- 
tocol message is relayed through the home IWF (typi- 
cally collocated with the wireless hub) to a PPP server 
of the private corporate intranet or ISP FIG. 27 depicts 
protocol stacks used for direct internet access by a 
roaming but fixed (i.e., non-moving) or a moving end 
system where the PPP protocol terminates in the home 
IWF (typically located in amobile switching centerof the 
home network) which relays message to and from an IP 
router. In FIG. 27, note how message traffic passes 
through a serving IWF (typically collocated with the wire- 
less hub) in addition to the home IWF. FIG. 28 depicts 
protocol stacks used for remote intranet access (i.e., ei- 
ther private corporate nets or an ISP) by a roaming but 
fixed (i.e., non-moving) or a moving end system where 
a PPP protocol message is relayed through the home 
IWF (typically located in a mobile switching centerof the 
home network) to a PPP server of the private corporate 
intranet or ISP. In FIG. 28, note how message traffic 
passes through a serving IWF (typically collocated with 
the wireless hub) in addition to the home IWF. When the 
serving IWF and the wireless hub are co-located in the 
same nest of computers or are even programmed into 
the same computer, it is not necessary to establish a 
tunnel using the XTunnel protocol between the serving 
IWF and the wireless hub. 

[01 81] Equivalent variations to these protocol stacks 
(e.g. the RLP can be terminated at the wireless hub rath- 
er than at the serving IWF or home IWF for mobiles at 



home) are also envisioned. If the IWF is located far from 
the wireless hub, and the packets can potentially be car- 
ried over a lossy IP network between the IWF and wire- 
less hub, then it would be preferred to terminate the RLP 
protocol at the wireless hub. Another variation is the 
Xtunnel between wireless huband IWF need not be built 
on top of the UDP/IP. Xtunnels can be built using the 
Frame Relay/ATM link layer. However, the use of UDP/ 
IP makes it easier to move the wireless hub and IWF 
software from one network to another. 
[0182] Four types of handoff scenarios may occur, 
and they are labeled: (i) local mobility, (ii) micro mobility, 
(iii) macro mobility, and (iv) global mobility. In all four 
scenarios (in one embodiment of the invention), a route 
optimization option is not considered so that the loca- 
tions of the home registration server and the ISP's PPP 
server do not change. In another embodiment of the in- 
vention with route optimization, the ISP's PPP server 
may change. However, this aspect is discussed below. 
In addition, the locations of the foreign registration serv- 
er and IWF do not change in the first three scenarios. 
[0183] The proposed IETF Mobile IP standard re- 
quires that whenever an end system changes the IP 
subnet to which it is attached, it sends a registration re- 
quest message to a home agent in its home subnet. This 
message carries a care-of address where the end sys- 
tem can be reached in the new subnet. When traffic is 
sent, for example, from an ISP to an end system, the 
home agent intercepts the traffic that is bound for the 
end system as it that arrives in the home subnet, and 
then forwards the traffic to the care-of address. The 
care-of address identifies a particular foreign agent in 
the foreign subnet. An end system's foreign agent can 
reside in the end system itself, or in a separate node 
that in turn forwards traffic to the end system (i.e., proxy 
registration agent). Mobile IP handoffs involve ex- 
change of control messages between an end system's 
agent, the end system's home agent and potentially its 
corresponding hosts (CHs) (with route optimization op- 
tion). 

[0184] The proposed IETF Mobile IP standard would 
find it difficult meet the latency and scalability goals for 
all movements in a large internetwork. However, the 
present hierarchical mobility management meets such 
goals. For small movements (e.g. a change of Access 
Points), only MAC-layer re-registrations are needed. 
For larger movements, network-layer re-registrations 
are performed. The present hierarchical mobility man- 
agement is different from the flat-structure used in the 
IETF proposed Mobile-IP standard as well as the serv- 
ing/anchor inter-working function model used in cellular 
systems like CDPD (based on a standard sponsored by 
the Cellular Digital Packet Data forum). 
[0185] As depicted in FIG. 29, the local mobility hand- 
off handles end system (designated MN for mobile 
node) movement between APs that belong to the same 
wireless hub. Thus, only MAC layer re-registration is re- 
quired. The end system receives a wireless hub adver- 
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tisement from a new AP and responds with a registration 
request addressed to the new AR 
[0186] ThenewAP (i.e., theonethat receives the reg- 
istration request from the end system) creates new en- 
tries in its connection table and relays the registration s 
message to its wireless hub. In local mobility handoffs, 
the wireless hub does not change. The wireless hub rec- 
ognizes the end system's registration request as a MAC 
level registration request, and it updates its connection 
table to reflect the connection to the new AP. Then, the 10 
old AP deletes the connection entry from its connection 
table. There are at least three ways whereby the old AP 
can delete the old entries, namely (i) upon time out, (ii) 
upon receiving a copy of the relayed MAC layer associ- 
ation message from the new AP to the wireless hub (if is 
this relay message is a broadcast message), and (iii) 
upon being informed by the wireless hub of the need to 
delete the entry. 

[0187] As depicted in FIG. 30, the micro mobility 
handoff handles end system (designated MN for mobile 20 
node) movement between wireless hubs that belong to 
the same registration server and where the end system 
can still be served by the existing serving IWF. When an 
advertisement is received from a new wireless hub 
(through a new AP), the end system sends a message 2$ 
to request registration to the registration server. The reg- 
istration request is relayed from the new AP to the new 
wireless hub to the registration server. 
[0188] When the registration server determines that 
the existing IWF can still be used, the registration server 30 
sends a build XTunnel Request message to request the 
existing IWF to build an XTunnel to the new wireless 
hub. Later, the registration server sends a tear down 
XTunnel request message to request the existing IWF 
to tear down the existing XTunnel with the old wireless 35 
hub. The build and tear XTunnel Request messages can 
be combined into one message. A foreign registration 
server does not forward the registration message to the 
home registration server since there is no change of 
IWF, either the serving IWF or home IWF. 40 
[0189] Upon receiving a positive build XTunnel reply 
and a positive tear XTunnel reply from IWF, the regis- 
tration server sends a registration reply to end system. 
As the registration reply reaches the new wireless hub, 
the connection table at the new wireless hub is updated 45 
to reflect the connection to the new AP. The new AP up- 
dates its MAC filter address table and connection table 
after receiving a message from the new wireless hub, 
and the registration reply is forwarded to the end sys- 
tem, so 
[0190] The registration server sends a release mes- 
sage to the old wireless hub. When the old wireless hub 
receives the release message, it updates its connection 
table and the MAC filter address table and connection 
table of the old AP. ss 
[0191] As depicted in FIG. 31, the macro mobility 
handoff case handles movement between wireless hubs 
that involves a change of the serving IWF in the foreign 



network, but it does not involve a change in the regis- 
tration server. When an advertisement is received from 
a new wireless hub (through a new AP), the end system 
sends a message to request a network layer registration 
to the registration server. The registration request is re- 
layed from the new AP to the new wireless hub to the 
registration server. 

[0192] The registration server recognizes that it is a 
foreign registration server when the end system does 
not belong to the present registration server's network. 
This foreign registration server determines the identity 
of the home registration server by using a request, pref- 
erably a Radius Access request (RA request), to the for- 
eign directory server (like a big yellow pages) and then 
assigns an appropriate IWF to be the serving IWF, and 
it forwards a registration request to the home registra- 
tion server, preferably through a Radius Access request 
(RA request), informing the home registration server of 
the newly selected IWF. 

[01 93] The home registration server authenticates the 
registration request by using a request, preferabty a Ra- 
dius Access request (RA request), to the home directory 
server. Upon authenticating the request and determin- 
ing that the existing home IWF can still be used, the 
home registration server instructs the home IWF to build 
a new l-XTunnel to the newly assigned serving IWF and 
to tear down the existing I -XTunnel to the old serving 
IWF. Upon receiving a positive build l-XTunnel reply and 
a positive tear l-XTunnel reply from the home IWF, the 
home registration server sends a registration reply to the 
foreign registration server. 

[0194] The foreign registration server then instructs 
the newly assigned IWF to build an XTunnel to the new 
wireless hub. Upon receiving a positive build XTunnel 
reply, the foreign registration server instructs the old 
IWF to tear down the XTunnel to the old wireless hub. " 
Upon receiving a positive build XTunnel reply and a pos- 
itive tear XTunnel reply, the foreign registration server 
sends a registration reply to end system. 
[01 95] As the registration reply reaches the new wire- 
less hub, the connection table at the new wireless hub 
is updated to reflect the connection to the new AP. The 
new AP updates its MAC filter address table and con- 
nection table after receiving a message from the new 
wireless hub, and the registration reply is forwarded to 
the end system. 

[0196] The registration server sends a release mes- 
sage to the old wireless hub. When the old wireless hub 
receives the release message, it updates its connection 
table and the MAC filter address table, and the old AP 
updates its MAC filter address table and connection ta- 
ble after receiving a message from the old wireless hub. 
[0197] The global mobility handoff case handles 
movement between wireless hubs that involves a 
change of registration servers. FIG. 32 depicts a global 
mobility handoff where the home IWF does not change, 
and FIG. 33 depicts a global mobility handoff where the 
home IWF changes. When an advertisement is received 
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from a new wireless hub (through a new AP) in a new 
foreign network, the end system sends a message to 
request a network layer registration to the new foreign 
registration server. The registration request is relayed 
from the new AP to the new wireless hub to the new 
foreign registration server. 

[0198] The registration server recognizes that it is a 
new foreign registration server when the end system 
does not belong to the present registration server's net- 
work. This foreign registration server determines the 
identity of the home registration server by using a re- 
quest, preferably a Radius Access request (RA re- 
quest), to the foreign directory server (like a big yellow 
pages) and then assigns an appropriate IWF to be the 
serving IWF, and it forwards the registration request to 
the home registration server, preferably through a Ra- 
dius Access request (RA request), informing the home 
registration server of the newly selected IWF. 
[01 99] The home registration server authenticates the 
registration request by using a request, preferably a Ra- 
dius Access request (RA request), to the home directory 
server. Upon authenticating the request and determin- 
ing that the existing home IWF can still be used (FIG. 
32), the home registration server instructs the home IWF 
to build a new l-XTunnel to the serving IWF newly as- 
signed by the new foreign registration server The home 
registration server also sends a de-registration mes- 
sage to the old foreign registration server and instructs 
the home IWF to tear down the existing l-XTunnel to the 
existing serving IWF of the old foreign network. Upon 
receiving a positive build l-XTunnel reply and a positive 
tear l-XTunnel reply from the home IWF, the home reg- 
istration server sends a registration reply to the new for- 
eign registration server 

[0200] The new foreign registration server then in- 
structs the newly assigned IWF to build an XTunnel to 
the new wireless hub. Upon receiving a positive build 
XTunnel reply, the foreign registration server sends a 
registration reply to end system. As the registration reply 
reaches the new wireless hub, the connection table at 
the new wireless hub is updatedto reflect the connection 
to the new AP The new AP updates its MAC filter ad- 
dress table and connection table after receiving a mes- 
sage from the new wireless hub, and the registration re- 
ply is forwarded to the end system. 
[0201] The old foreign registration server instructs the 
old IWF to tear down the XTunnel to the old wireless 
hub. Upon receiving a positive tear XTunnel reply or 
contemporaneously with the tear down XTunnel re- 
quest, the old foreign registration server sends a release 
message to the old wireless hub. When the old wireless 
hub receives the release message, it updates its con- 
nection table and the MAC filter address table, and the 
old AP updates its MAC filter address table and connec- 
tion table after receiving a message from the old wire- 
less hub. 

[0202] Alternatively, afterthehome registration server 
authenticates the registration request from the new for- 



eign registration server and determines that the existing 
home IWF cannot be used (FIG. 33), the home registra- 
tion server chooses a new home IWF and instructs the 
new home IWF to build a new level 2 tunnel protocol 
s tunnel (L2TP tunnel) to the present PPP server (e.g., 
the PPP server in a connected ISP intranet). Then, the 
home registration server instructs the old home IWF to 
transfer its L2TP tunnel traffic to the new home IWF. 
[0203] Then the home registration server instructs the 
new home IWF to build a new l-XTunnel to the serving 
IWF newly assigned by the new foreign registration 
server. The home registration server also sends a de- 
registration message to the old foreign registration serv- 
er and instructs the home IWF to tear down the existing 
l-XTunnel to the existing serving IWF of the old foreign 
network. Upon receiving a positive build l-XTunnel reply 
and a positive tear l-XTunnel reply from the home IWF, 
the home registration server sends a registration reply 
to trie new foreign registration server. 
[0204] The new foreign registration server then in- 
structs the newly assigned IWF to build an XTunnel to 
the new wireless hub. Upon receiving a positive build 
XTunnel reply, the foreign registration server sends a 
registration reply to end system. As the registration reply 
reaches the new wireless hub, the connection table at 
the new wireless hub is updatedto reflect the connection 
to the new AP. The new AP updates its MAC filter ad- 
dress table and connection table after receiving a mes- 
sage from the new wireless hub, and the registration re- 
ply is forwarded to the end system. 
[0205] The old foreign registration server instructs the 
old IWF to tear down the XTunnel to the old wireless 
hub. Upon receiving a positive tear XTunnel reply or 
contemporaneously with the tear down XTunnel re- 
quest, the old foreign registration server sends a release 
message to the old wireless hub. When the old wireless 
hub receives the release message, it updates its con- 
nection table and the MAC filter address table, and the 
old AP updates its MAC filter address table and connec- 
tion table after receiving a message from the old wire- 
less hub. 

[0206] End systems constructed according to the 
present invention interoperate with networks construct- 
ed according to the proposed IETF Mobile-IP standards, 
and end systems constructed according to the proposed 
IETF Mobile-IP standards interoperate with networks 
constructed according to the present invention. 
[0207] The main differences between the present in- 
vention and the IETF Mobile-IP (rfc2002, a standards 
document) are: 

(i) The present invention uses a hierarchical con- 
cept for mobility management rather than a flat 
structure as in the proposed IETF Mobile-IP stand- 
ard. Small mobility within a small area does not re- 
sult in a network level registration. Micro mobility in- 
volves setting up of a new Xtunnel and tearing down 
of an existing Xtunnel. Global mobility, at the mini- 
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mum, involves setting up of a new l-XTunnel and 
tearing down of an existing l-Xtunnel apart from the 
setting up/tearing down of XTunnel. Global mobility 
sometimes also involves setting up a new L2TP 
Tunnel and transferring of L2TP state from the ex- 
isting L2TP Tunnel to the new L2TP Tunnel. 

(ii) In the present invention, a user name plus a 
realm is used to identify a remote dial-up user rather 
than a fixed home address as in the case of the pro- 
posed IETF Mobile-IP standard. 

(iii) In the present invention, registration and routing 
functions are carried out by separate entities. The 
two functions are carried out by the home agent in 
the proposed IETF Mobile IP standard, and both 
functions are carried out by the foreign agent in the 
proposed I EFT Mobile IP standard. In contrast, in 
an embodiment of the present invention, registra- 
tion is carried out in the registration server and rout- 
ing functions are carried out by both the home and 
foreign IWF and the wireless hub (also referred to 
as the access hub). 

(iv) The present invention utilizes three tunnels per 
PPP session. The.XTunnel is more of a link-layer 
tunnel between the wireless hub and the serving 
IWF. The l-XTunnel between the serving IWF and 
the home IWF is more like the tunnel between home 
and foreign agents in the proposed IETF Mobile-IP 
standard. The L2TP tunnel is used only when home 
IWF is not a PPP server. 

(v) In the present invention, network layer registra- 
tion occurs before PPP session starts while in the 
proposed IETF Mobile-IP standard, Mobile-IP reg- 
istration occurs after PPP session enters into the 
open state. 

(vi) In the present invention, the network entity that 
advertises the agent advertisement (i.e., the wire- 
less hub) is not on a direct link to the end systems 
whereas for the proposed IETF Mobile-IP standard, 
the agent advertisement must have a TTL of 1 
which means that the end systems have a direct link 
with the foreign agent. In addition, the agent adver- 
tisement in the present invention is not an extension 
to the ICMP router advertisements as in the pro- 
posed IETF Mobile-IP standard. 

[0208] End systems in the present invention, should 
support agent solicitation. When an end system in the 
present invention visits a network which is supporting 
the proposed IETF Mobile-IP standard, it waits until it 
hears an agent advertisement. If it does not receive an 
agent advertisement within a reasonable time frame, it 
broadcasts an agent solicitation. 
[0209] In the present invention, network operators 



may negotiate with other networks that support the pro- 
posed IETF Mobile-IP standard such that home ad- 
dresses can be assigned to the end systems of the 
present invention that wish to use other networks. When 
s the end system of the present invention receives the 
agent advertisement, it can determine that the network 
it is visiting is not an a network according to the present 
invention and hence uses the assigned home address 
to register 

[0210] For networks supporting the proposed IETF 
Mobile-IP standard, the PPP session starts before Mo- 
bile-IP registration, and the PPP server is assumed to 
be collocated with the foreign agent in such networks. 
In one embodiment, an SNAP header is used to encap- 
sulate PPP frames in the MAC frames of the present 
invention (in a manner similar to Ethernet format), and 
the foreign agent interprets this format as a proprietary 
PPP format over Ethernet encapsulation. Thus, the end 
system of the present invention and its PPP peer can 
enter into an open state before the foreign agent starts 
transmitting an agent advertisement, and the end sys- 
tem of the present invention can register. 
[0211] To allow end systems supporting the proposed 
IETF Mobile-IP standard to work in networks of the type 
of the present invention, such mobiles are at least ca- 
pable of performing similar MAC layer registrations. By 
making the agent advertisement message format simi- 
lar to the proposed Mobile-IP standard agent advertise- 
ment message format, a visiting end system can inter- 
pret the agent advertisement and register with a wire- 
less hub. In the present invention, registration request 
and reply messages are similar to the proposed IETF 
Mobile-IP standard registration request and reply mes- 
sages (without any unnecessary extensions) so that the 
rest of the mobility management features of the present 
invention are transparent to the visiting end systems. 
[0212] Since end systems supporting the proposed 
IETF Mobile-IP standard expect a PPP session to start 
before Mobile-IP registration, an optional feature in wire- 
less hubs of the present invention starts to interpret PPP 
LCR NCP packets after MAC-layer registrations. 
[0213] To avoid losing traffic during handoffs, the mo- 
bility management of the present invention uses the 
make before break concept. For local mobility, a make 
before break connection is achieved by turning the 
MAC-layer registration message relayed by the new AP 
to the wireless hub into a broadcast message. That way, 
the old AP can hear about the new registration and for- 
ward packets destined for the end system that have not 
been transmitted to the new AP. 
[0214] For micro mobility, information about the new 
wireless hub is included in the Tear XTunnel message 
exchanged between the serving IWF and the old WH. 
That way, the old wireless hub can forward buffered 
packets to the new wireless hub upon hearing a TearX- 
Tunnel message from the serving IWF. Alternatively, the 
RLP layer at the IWF knows the sequence number that 
has been acknowledged by the old wireless hub so far. 
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[0215] At the same time, the IWF knows the current 
send sequence number of the latest packet sent to the 
old wireless hub. Therefore, the IWF can forward those 
packets that are ordered in between these two numbers 
to the new wireless hub before sending newer packets 
to the new wireless hub. The RLP layer is assumed to 
be able to filter duplicate packet. The second approach 
is probably preferable to the first approach for the old 
wireless hub may not be able to communicate with one 
another directly. 

[021 6] For macro mobility, the old serving IWF can for- 
ward packets to the new serving IWF, in addition to the 
packet forwarding done from the old wireless hub to the 
new wireless. All we need to do is to forward the new 
serving IWF identity to the new serving IWF in the tear 
down l-XTunnel message. Another way to achieve the 
same result is to let the home IWF forward the missing 
packets to the new serving IWF rather than asking the 
old serving IWF to do the job since the home IWF knows 
the l-XTunnel sequence number last acknowledged by 
the old serving IWF and the current l-XTunnel sequence 
number sent by the home IWF. 
[0217] The method of estimating how much buffer 
should be allocated per mobile per AP per wireless hub 
per IWF such that the traffic loss between handoffs can 
be minimized is to let the end system for the AP for the 
wireless hub for the IWF estimate the packet arrival rate 
and the handoff time. This information is passed to the 
old AP of the wireless hub of the IWF to determine how 
much traffic should be transferred to the new AP of the 
wireless hub of the IWF, respectively, upon handoffs. 
[021 8] To achieve route optimization in the present in- 
vention, the end system chooses the PPP server closest 
to the serving IWF. Without route optimization, exces- 
sive transport delays and physical line usage may be 
experienced. 

[0219] For example, an end system subscribed to a 
home network in New York City may roam to Hong Kong. 
To establish a link to a Hong Kong ISR the end system 
would have a serving IWF established in a wireless hub 
in Hong Kong and a home IWF established in the home 
network in New York City, A message would then be 
routed from the end system (roamed to Hong Kong) 
through the serving IWF (in Hong Kong) and through the 
home IWF (in New York City) and back to the Hong Kong 
ISP. 

[0220] A preferred approach is to connect from the 
serving IWF (in Hong Kong) directly to the Hong Kong 
ISP. The serving IWF acts like the home IWF In this em- 
bodiment, roaming agreements exist between the home 
and foreign wireless providers. In addition, the various 
accounting/billing systems communicate with one an- 
other automatically such that billing information is 
shared. Accounting and billing information exchange 
may be implemented using standards such as the 
standard proposed by the ROAMOPS working group of 
the IETF. 

[0221] However, the serving IWF must still discover 



the closest PPP server (e.g., the Hong Kong ISP). In the 
present embodiment, the foreign registration server 
learns of the end system's desire to connect to a PPP 
server (e.g., a Hong Kong ISP) when it receives a reg- 
s istration request from the end system. When the foreign 
registration server determines that the serving IWF is 
closer to the desired PPP server (e.g., the Hong Kong 
ISP) than the home IWF is, the foreign registration serv- 
er instructs the serving IWF to establish an L2TP tunnel 
to its nearest PPP server (in contrast to the PPP server 
closest to the home registration server and home IWF). 
Then, the foreign registration server informs the home 
registration server that the end system is being served 
by the serving IWF and the foreign PPP. 
[0222] In an alternative embodiment, the foreign reg- 
istration server determines that the serving IWF is closer 
to the desired PPP server (e.g., the Hong Kong ISP) 
than the home IWF is, when it receives a registration 
request from the end system. The foreign registration 
server relays the registration request message to the 
home registration server with an attached message in- 
dicating the serving IWF information and a notification 
that route optimization is preferred. At the same time, 
the foreign registration server instructs the serving IWF 
to establish an L2TP tunnel to the PPP server. Upon ap- 
proving the registration request, the home registration 
server instructs the home IWF to transfer the L2TP state 
to the foreign IWF. 

[0223] In FIG. 34, data frames are initially communi- 
cated between the first mobile end system and the first 
access hub through the first access point. Then, a reg- 
istration request is sent from the first mobile end system 
through the second access point to the first access hub 
to re-register the first mobile end system with the first 
access hub without informing the first registration server 
when the first mobile end system moves and re-regis- 
ters through the second access point. Finally, the sec- 
ond access point is linked with the first access hub when 
the first mobile end system re-registers through the sec- 
ond access point, and the first access point is de-linked 
from the first access hub when the second access point 
is linked with the first access hub. 
[0224] In FIG. 35, data frames are initially communi- 
cated between the first mobile end system and the first 
inter-working function through the first access hub. 
Then, a registration request is sent from the first mobile 
end system through a first access point and through the 
second access hub to the first registration server to re- 
register the first mobile end system with the first regis- 
tration server without informing the home registration 
server when the first mobile end system moves and re- 
registers through the second access hub. Finally, the 
second access hub is linked with the first inter-working 
function when the first mobile end system re-registers 
through the second access hub, and the first access hub 
is de-linked from the first inter-working function after the 
second access hub is linked with the first inter-working 
function. 
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[0225] In FIG. 36, data frames are initially communi- 
cated between the first mobile end system and the third 
inter-working function through the first inter-working 
function, and data frames are initially communicated be- 
tween the third inter-working function and the first com- s 
munications server. Then, a registration request is sent 
from the first mobile end system through a first access 
point and through the first access hub and through the 
first registration server to the home registration server 
to re-register the first mobile end system with the home 10 
registration server without de-linking the third inter- 
working function from the first communications server 
when the first mobile end system moves and re-regis- 
ters through the first access hub. The step of sending 
the registration request from the first registration server '5 
to the home registration server sends an indication of a 
change from the first inter-working function to the sec- 
ond inter-working function. Finally, the second inter- 
working function is linked with the third inter-working 
function when the first mobile end system re-registers 20 
through the first access hub, and the first inter-working 
function is de-linked from the third inter-working function 
after the second inter-working function is linked with the 
third inter-working function. 

[0226] In FIG. 37, data frames are initially communi- 25 
cated between a first mobile end system and the third 
inter-working function through the first inter-working 
function, and data frames are initially communicated be- 
tween the third inter-working function and the first com- 
munications server. Then, a registration request is sent 30 
from the first mobile end system through a first access 
point and through the first access hub and through the 
second registration server to the home registration serv- 
er to re-register the first mobile end system with the 
home registration server without de-linking the third in- 35 
ter-working function from the first communications serv- 
er when the first mobile end system moves and re-reg- 
isters through the first access hub. Finally, the third inter- 
working function is linked with the second inter-working 
function when the first mobile end system re-registers 40 
through the first access hub, and the third inter-working 
function is de-linked from the first inter-working function 
after the third inter-working function is linked with the 
second inter-working function. 

[0227] In FIG. 38, data frames are initially communi- 4$ 
cated between a first mobile end system and the third 
inter-working function through the first inter-working 
function, and data frames are nitially communicated be- 
tween the third inter-working function and the first com- 
munications server. Then, a registration request is sent so 
from the first mobile end system through a first access 
point and through the first access hub and through the 
second registration server to the home registration serv- 
er to re-register the first mobile end system with the 
home registration server when the first mobile end sys- 55 
tern moves and re-registers through thefirst access hub. 
Finally, the fourth inter-working function is linked with the 
second inter-working function when the first mobile end 



system re-registers through the first access hub, the 
fourth inter-working function is linked with the first com- 
munications server, the third inter-working function is 
de-linked from the first communications server when the 
fourth inter- working function is linked with the first com- 
munications server, and the third inter-working function 
is de-linked from the first inter-working function after the 
fourth inter-working function is linked with the second 
inter-working function. 

[0228] The wireless data network include a home mo- 
bility switching center, a foreign mobility switching cent- 
er, a base station and an end user. The home mobility 
switching center includes a home registration server 
and a home inter-working function. The foreign mobility 
switching center includes a serving registration server 
and a serving inter-working function. The base station 
includes a proxy registration agent. The end user mo- 
dem includes a user registration agent. The user regis- 
tration agent is coupled to the proxy registration agent, 
the proxy registration agent is coupled to the serving 
registration server, and the serving registration server is 
coupled to the home registration server. The proxy reg- 
istration agent includes a module to send an advertise- 
ment containing a care-of-address when the proxy reg- 
istration agent receives a solicitation from the user reg- 
istration agent, and the user registration agent includes 
a module to incorporate user identity information and the 
care-of-address in a registration request when the user 
registration agent receives the advertizement and a 
module to send this registration request to the proxy reg- 
istration agent. The proxy registration agent includes a 
module to forward to the serving registration server any 
registration request received from any user. The serving 
registration server includes a foreign directory module 
to determine a home registration server address, a mod- 
ule to encapsulate the registration request and incorpo- 
rate serving registration server identity information and 
the encapsulated registration request in a radius access 
request when the home registration server address is 
determined, and a module to send the radius access re- 
quest to the home registration server. The home regis- 
tration server includes a home directory module to au- 
thenticate the serving registration server identity infor- 
mation, a module to form an inter-working function re- 
quest from the radius access request when the serving 
registration server identity information is authenticated, 
and a module to send the inter-working request to the 
home inter-working function. 
[0229] Having described preferred embodiments of a 
novel network architecture with wireless end users able 
to roam (which are intended to be illustrative and not 
limiting), it is noted that modifications and variations can 
be made by persons skilled in the art in light of the above 
teachings. For example, connection links described 
herein may make reference to known connection proto- 
cols (e.g., IP, TCP/IP, L2TP, IEEE 802.3, etc.); however, 
the invention contemplates other connection protocols 
in the connections links that provide the same or similar 
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data delivery capabilities. Acting agents in the above de- 
scribed embodiments may be in the form of software 
controlled processors or may be other form of controls 
(e.g., programmable logic arrays, etc.). Acting agents 
may be grouped as described above or grouped other- 
wise in keeping with the connection teachings described 
herein and subject to security and authentication teach- 
ings as described herein. Furthermore, a single access 
point, access hub (i.e., wireless hub) or inter-working 
function unit (IWF unit) may provide multi-channel ca- 
pability. Thus, a single access point or access hub or 
IWF unit may act on traffic from multiple end systems, 
and what is described herein as separate access points, 
access hubs or IWF units contemplates equivalence 
with a single multichannel access point, access hub or 
IWF unit. It is therefore to be understood that changes 
may be made in the particular embodiments of the in- 
vention disclosed which are within the scope and spirit 
of the invention as defined by the appended claims. 



Claims 

1 . A communications system comprising: 

a network that includes a first registration serv- 
er and first and second access points and a first 
access hub, the network initially communicat- 
ing data frames between a first mobile end sys- 
tem and the first access hub through the first 
access point; 

wherein the first access hub includes a first 
module to re-register the first mobile end sys- 
tem with the first access hub without informing 
the first registration server when a registration 
request is received from the first mobile end 
system through the second access point; 

wherein the first access hub further includes a 
. second module to link the second access point 
with the first access hub when the mobile end 
system re-registers through the second access 
point; and 

wherein the first access hub further includes a 
third module to de-link the first access point 
from the first access hub when the second ac- 
cess point is linked with the first access hub. 

2. The system of claim 1 , wherein: 

the network is regarded as a foreign network 
■ and the foreign network further includes second 
and third access hubs and a first inter-working 
function, the foreign network initially communi- 
cating data frames between a second mobile 
end system and the first inter-working function 



through the second access hub; 

a home network includes a home registration 
server; 

5 

the first registration server includes a first mod- 
ule to re-register the second mobile end system 
with the first registration server without inform- 
ing the home registration server when a regis- 
10 tration request is received from the second mo- 

bile end system through a third access point 
and through the third access hub; 

the first registration server further includes a 
15 second module to cornand the third access hub 

to be linked with the first inter-working function 
when the second mobile end system re-regis- 
ters through the third access hub; and 

20 the first registration server further includes a 

third module to command the second access 
hub to be de-linked from the first inter-working 
function after the third access hub is linked with 
the first inter-working function. 

2$ 

3. The system of claim 2, wherein: 

the foreign network further includes a fourth ac- 
cess hub and second and third inter-working 
30 functions; 

the home network further includes a fourth in- 
ter-working function, the foreign network initial- 
ly communicating data frames between a third 
35 mobile end system and the fourth inter-working 

function through the second inter-working func- 
tion, the home network initially communicating 
data frames between the fourth inter-working 
function and a first communications server; 

40 

the home registration server includes a first 
module to re-register the third mobile end sys- 
tem with the home registration server without 
de-linking the fourth inter-working function from 

45 the first communications server when a regis- 

tration request is received from the third mobile 
end system through a fourth access point and 
through the fourth access hub and through the 
first registration server, the first module recog- 

50 nizing an indication in the registration request 

of a change from the second inter-working func- 
tion to the third inter-working function; 

the home registration server further includes a 
55 second module to cornand the fourth inter- 

working function to be linked with the third inter- 
working function when the third mobile end sys- 
tem re-registers through the fourth access hub; 
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and 

the home registration server further includes a 
third module to comand the fourth inter-working 
function to be de-linked from the second inter- 5 
working function after the third inter-working 
function is linked with the fourth inter-working 
function. 

4. The system of claim 3, wherein: 10 

the foreign network is regarded as a first foreign 
network and the first foreign network further in- 
cludes a fifth inter-working function; 

15 

a second foreign network includes a second 
registration server and a fifth access hub and a 
sixth inter-working function; 

the home network further includes a seventh in- 20 
ter- working function, the first foreign network 
initially, communicating data frames between a 
fourth mobile end system and the seventh inter- 
working function through the fifth inter-working 
function, the home network initially communi- 25 
eating data frames between the seventh inter- 
working function and a second communica- 
tions server; 

the home registration server further includes a 30 
fourth module to re-register the fourth mobile 
end system with the home registration server 
without de-linking the seventh inter-working 
function from the second communications serv- 
er when a registration request is received from 35 
the fourth mobile end system through a fifth ac- 
cess point and through the fifth access hub and 
through the second registration server to the 
home registration server; 

40 

the home registration server further includes a 
fifth module to command the seventh inter- 
working function to be linked with the sixth inter- 
working function when the fourth mobile end 
system re-registers through the fifth access & 
hub; and 

the home registration server further includes a 
sixth module to command the seventh inter- 
working function to be de-linked from the fifth so 
inter-working function after the sixth inter-work- 
ing function is linked with the seventh inter- 
working function. 

5. The system of claim 3, wherein: ss 

the foreign network is regarded as a first foreign 
network and the first foreign network further in- 



cludes a fifth inter-working function; 

a second foreign network includes a second 
registration server and a fifth access hub and a 
sixth inter-working function; 

the home network further includes seventh and 
eighth inter-working functions, the first foreign 
network initially communicating data frames 
between a fourth mobile end system and sev- 
enth inter-working function through the fifth in- 
ter-working function, the home network initially 
communicating data frames between the sev- 
enth inter-working function and a second com- 
munications server; 

the home registration server further includes a 
fourth module to re-register the fourth mobile 
end system with the home registration server 
when a registration request is received from the 
fourth mobile end system through a fifth access 
point and through the fifth access hub and 
through the second registration server to the 
home registration server; 

the home registration server further includes a 
fifth module to command the eighth inter-work- 
ing function to be linked with the sixth inter- 
working function when the fourth mobile end 
system re-registers through the fifth access 
hub; 

the home registration server further includes a 
sixth module to command the eighth inter-work- 
ing function to be linked with the second com- 
munications server; 

the home registration server further includes a 
seventh module to command the seventh inter- 
working function to be de-linked from the sec- 
ond communications server; and 

the home registration server further includes an 
eighth module to command the seventh inter- 
working function to be de-linked from the fifth 
inter-working function after the eighth inter- 
working function is linked with the sixth inter- 
working function. 

6. A communications system comprising: 

a foreign network that includes a first registra- 
tion server and first and second access hubs 
and a first inter-working function, the foreign 
network initially communicating data frames 
between a first mobile end system and the first 
inter-working function through the first access 
hub; 
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a home network that includes a home registra- 
tion server; 

wherein the first registration server includes a 
first module to re-register the first mobile end 5 
system with the first registration server without 
informing the home registration server when a 
registration request is received from the first 
mobile end system through a first access point 
and through the second access hub to the first 10 
registration server; 

wherein the first registration server further in- 
cludes a second module to command the sec- 
ond access hub to be linked with the first inter- is 
working function when the first mobile end sys- 
tem re-registers through the second access 
hub; and 

wherein the first registration server further in- 20 
eludes a third module to command the first ac- 
cess hub to be de-linked from the first inter- 
working function after the second access hub 
is linked with the first inter-working function. 

25 

7. The system of claim 6, wherein: 

the foreign network further includes a third ac- 
cess hub and second and third inter-working 
functions; so 



ter-working function when the second mobile 
end system re-registers through the third ac- 
cess hub; and 

the home registration server further includes a 
third module to command the second inter- 
working function to be de-linked from the fourth 
inter-working function after the third inter-work- 
ing function is linked with the fourth inter-work- 
ing function. 

8. The system of claim 7, wherein: 

the foreign network is regarded as a first foreign 
network and the first foreign network further in- 
cludes a fifth inter-working function; 

a second foreign network includes a second 
registration server and a fourth access hub and 
a sixth inter-working function; 

the home network further includes a seventh in- 
ter-working function, the first foreign network 
initially communicating data frames between a 
third mobile end system and the seventh inter- 
working function through the fifth inter-working 
function, the home network initially communi- 
cating data frames between the seventh inter- 
working function and a second communica- 
tions server; 



the home network further includes a fourth in- 
ter-working function, the foreign network initial- 
ly communicating data frames between a sec- 
ond mobile end system and the fourth inter- 35 
working function through the second inter- 
working function, the home network initially 
communicating data frames between the fourth 
inter-working function and a first communica- 
tions server; 40 

the home registration server includes a first 
module to re-register the second mobile end 
system with the home registration server with- 
out de-linking the fourth inter-working function 45 
from the first communications server when a 
registration request is received from the second 
mobile end system through a second access 
point and through the third access hub and 
through the first registration server to the home 50 
registration server, the first module recognizing 
an indication in the registration request of a 
change from the second inter-working function 
to the third inter-working function; 

ss 

the home registration server further includes a 
second module to command the third inter- 
working function to be linked with the fourth in- 



the home registration server further includes a 
fourth module to re-register the third mobile end 
system with the home registration server with- 
out de-linking the seventh inter-working func- 
tion from the second communications server 
when a registration request is received from the 
third mobile end system through a third access 
point and through the fourth access hub and 
through the second registration server to the 
home registration server; 

the home registration server further includes a 
fifth module to command the sixth inter-working 
function to be linked with the seventh inter- 
working function when the third mobile end sys- 
tem re-registers through the fourth access hub; 
and 

the home registration server further includes a 
sixth module to command the fifth inter-working 
function to be de-linked from the seventh inter- 
working function after the sixth inter-working 
function is linked with the seventh inter-working 
function. 

The system of claim 7, wherein: 
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the foreign network is regarded as a first foreign 
network and the first foreign network further in- 
cludes a fifth inter-working function; 

a second foreign network includes a second £ 
registration server and a fourth access hub and 
a sixth inter-working function; 

the home network further includes seventh and 
eighth inter-working functions, the first foreign 10 
network initially communicating data frames 
between a third mobile end system and seventh 
inter-working function through the fifth inter- 
working function, the home network initially 
communicating data frames between the sev- *5 
enth inter-working function and a second com- 
munications server; 

the home registration server further includes a 
fourth module to re-register the third mobile end 20 
system with the home registration server when 
a registration request is received from the third 
mobile end system through a third access point 
and through the fourth access hub and through 
the second registration server to the home reg- 2$ 
istration server; 

the home registration server further includes a 
fifth module to command the eighth inter-work- 
ing function to be linked with the sixth inter- 30 
working function when the third mobile end sys- 
tem re-registers through the fourth access hub; 

the home registration server further includes a 
sixth module tocommandthe eighth inter-work- 35 
ing function to be linked with the second com- 
munications server; 

the home registration server further includes a 
seventh module to command the seventh inter- 40 
working function to be de-linked from the sec- 
ond communications server; and 



the home registration serverfurther includes an 
eighth module to command the seventh inter- 
working function to be de-linked from the fifth 
inter-working function after the eighth inter- 
working function is linked with the sixth inter- 
working function. 

10. A communications system comprising: 



45 



so 



a foreign network that includes a first registra- 
tion server and a first access hub and first and 
second inter-working functions; 55 

a home network that include a home registra- . 
tion server and a third inter-working function, 



the foreign network initially communicating da- 
ta frames between a first mobile end system 
and the third inter-working function through the 
first inter-working function, the home network 
initially communicating data frames between 
the third inter-working function and the first 
communications server; 

wherein the home registration server includes 
a first module to re-register the first mobile end 
system with the home registration server with- 
out de-linking the third inter-working function 
from the first communications server when a 
registration request is received from the first 
mobile end system through a first access point 
and through the first access hub and through 
the first registration server to the home regis- 
tration server, the first module recognizing an 
indication in the registration request of a 
change from the first inter-working function to 
the second inter-working function; 

wherein the home registration serverfurther in- 
cludes a second module to command the sec- 
ond inter-working function to be linked with the 
third inter-working function when the first mo- 
bile end system re-registers through the first 
access hub; and 

wherein the home registration serverfurther in- 
cludes a third module to command the first in- 
ter-working function to be de-linked from the 
third inter-working function after the second in- 
ter-working function is linked with the third inter- 
working function. 

11. The system of claim 10, wherein: 

the foreign network is regarded as a first foreign 
network and the first foreign network further in- 
cludes fourth inter-working function; 

a second foreign network includes a second 
registration server and a second access hub 
and a fifth inter-working function; 

the home network further includes a sixth inter- 
working function, the first foreign network ini- 
tially communicating data frames between a 
second mobile end system and the sixth inter- 
working function through the fourth inter-work- 
ing function, the home network initially, commu- 
nicating data frames between the sixth inter- 
working function and a second communica- 
tions server; 

the home registration server further includes a 
fourth module to re-register the second mobile 
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end system with the home registration server 
without de-linking the sixth inter-working func- 
tion from the second communications server 
when a registration request is received from the 
second mobile end system through a second 
access point and through the second access 
hub and through the second registration server 
to the home registration server; 

the home registration server further includes a 
fifth module to command the fifth inter-working 
function to be linked with the sixth inter-working 
function when the second mobile end system 
re-registers through the second access hub; 
and 

the home registration server further includes a 
sixth module to command the fourth inter-work- 
ing function to be de-iinked from the sixth inter- 
working function after the fifth inter-working 
function is linked with the sixth inter-working 
function. 

12. The system of claim 10, wherein: 

the foreign network is regarded as a first foreign 
network and the first foreign network further in- 
cludes a fourth inter-working function; 

a second foreign network includes a second 
registration server and a second access hub 
and a fifth inter-working function; 

the home network further includes sixth and 
seventh inter-working functions, the first for- 
eign network initially, communicating data 
frames between a second mobile end system 
and the sixth inter-working function through the 
fourth inter-working function, the home network 
initially communicating data frames between 
the sixth inter-working function and a second 
communications server; 

the home registration server further includes a 
fourth module to re-register the second mobile 
end system with the home registration server 
when a registration request is received from the 
second mobile end system through a second 
access point and through the second access 
hub and through the second registration server 
to the home registration server; 

the home registration server further includes a 
fifth module to command the fifth inter-working 
function to be linked with the seventh inter- 
working function when the second mobile end 
system re-registers through the second access 
hub; 



the home registration server further includes a 
sixth module to command the seventh inter- 
working function to be linked with the second 
communications server; 

5 

the home registration server further includes a 
seventh module to command the sixth inter- 
working function to be de-linked from the sec- 
ond communications server; and 

10 

the home registration server further includes an 
eighth module tocommand the sixth inter-work- 
ing function to be de-linked from the fourth in- 
ter-working function after the seventh inter- 
's working function is linked with the fifth inter- 
working function. 

13. A communications system comprising: 

20 a first foreign network that includes a first reg- 

istration server and a first inter-working func- 
tion; 

a second foreign network that includes a sec- 
2$ ond registration server and a first access hub 

and a second inter-working function; 

a home network that includes a home registra- 
tion server and a third inter-working function, 

30 the first foreign network initially communicating 

data frames between a first mobile end system 
and the third inter-working function through the 
first inter- working function, the home network 
initially communicating data frames between 

35 the third inter-working function and the first 

communications server; 

wherein the home registratation server in- 
cludes a first module to re-register the first mo- 

40 bile end system with the home registration serv- 

er without de-linking the third inter-working 
function from the first communications server 
when a registration request is received from the 
first mobile end system through a first access 

45 point and through the first access hub and 

through the second registration server to the 
home registration server; 

wherein the home registratation server further 
so includes a second module to command the 

third inter-working function to be linked with the 
second inter-working function when the first 
mobile end system re-registers through the first 
access hub; and 

55 

wherein the home registratation server further 
includes a third module to command the third 
inter-working function to be de-linked from the 
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first inter-working function after the third inter- 
working function is linked with the second inter- 
working function. 

14. A communications system comprising: 5 

a first foreign network that includes a first reg- 
istration server and a first inter-working func- 
tion; 

10 

a second foreign network that includes a sec- 
ond registration server and a first access hub 
and a second inter- working function; 

a home network that includes a home registra- * s 
tion server and third and fourth inter-working 
functions, the first foreign network initially com- 
municating data frames between a first mobile 
end system and the third inter-working function 
through the first inter-working function, the 20 
home network initially communicating data 
frames between the third inter-working function 
and the first communications server; 

wherein the home registratation server in- 25 
eludes a first module to re-register the first mo- 
bile end system with the home registration serv- 
er when a registration request is received from 
the first mobile end system through a first ac- 
cess point and through the first access hub and 30 
through the second registration server to the 
home registration server; 

wherein the home registratation server further 
includes a second module to command the 3$ 
fourth inter-working function to be linked with 
the second inter-working function when the first 
mobile end system re-registers through the first 
access hub; 

40 

wherein the home registratation server further 
indudes a third module to command the fourth 
inter- working function to be linked with the first 
communications server; 

45 

wherein the home registratation server further 
includes a fourth module to command the third 
inter-working function to be de-linked from the 
first communications server when the fourth in- 
ter-working function is linked with the first com- so 
munications server; and 

wherein the home registratation server further 
■ includes a fifth module to command the third 
inter-working function to be de-linked from the 55 
first inter-working function after the fourth inter- 
working function is linked with the second inter- 
working function. 
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